Re: RFD: C pointer conversions that differ in unsignedness

[schopper-gcc]

Shouldn't the compiler behave in the following way, concerning the signedness
of pointer arguments?

  void f (long *l, signed long *sl, unsigned long *ul);

  // - Make NO assumptions about the signedness of *l and accept long,
  //slong and ulong without a warning
  // - treat *sl as signed long and produce a warning if given a long
  //or unsigned long
  // - treat *ul as unsigned long and produce a warning if given a
  //long or signed long

  long *l;
  singend long *sl;
  unsigned long *ul;

  f ( l, sl, ul);//   No Warning 

  f (sl, sl, ul);//   No Warning
  f (ul, sl, ul);//   No Warning
  f ( l,  l, ul);//   Warning on second argument
  f ( l, ul, ul);//   Warning on second argument
  f ( l, sl,  l);//   Warning on third argument
  f ( l, sl, sl);//   Warning on third argument

Best regards

Rüdiger

> Code such as:
> 
> void f(long *, unsigned long *);
> 
> int main()
> {
> long *scp;
> unsigned long *ucp;
> 
> ucp = scp;
> scp = ucp;
> f(ucp, scp);
> }
> 
> is in violation of of the C standard.  We silently accept such code, 
> unless -pedantic (or better) is given.  I didn't happen to see this 
> listed in extentions.texi.
> 
> This was put in:
> 
> revision 1.91
> date: 1993/05/27 04:30:54;  author: rms;  state: Exp;  lines: +6 -7
> (convert_for_assignment): When allowing mixing of
> signed and unsigned pointers, compare unsigned types not type sizes.
> 
> in c-typeck.c, and before that (going back to 1.1), we always gave at 
> least a warning.  In C++, we give the warning.  Other compilers give 
> hard errors for these things.
> 
> I propose to tighten this up to a warning, unconditionally.  How to 
> others feel?  -Wall?  -std=?  Over my dead body?
> 
> Apple Radar 2535328.
> 
> 

> 2003-10-06  Mike Stump  <[EMAIL PROTECTED]>
> 
>   * c-typeck.c (convert_for_assignment): Tighted up pointer converstions
>   that differ in signedness.
> 

Re: RFD: C pointer conversions that differ in unsignedness

[schopper-gcc]

Oh right, what I really meant was 'char' instead of 'long'.
In fact I just took the type from the referenced article. Sorry for that.

So am I right that the compiler should distinguish between char, signed char
and unsigned char in the proposed way?


> 
> "long" and "signed long" are the same type.  You are confused about how
> C and C++ are defined.  Same with "int" and "signed int".  Only for "char"
> are things different; it is implementation-defined (can differ from
> platform to platform) whether "char" is signed or not.
>