RFD: C pointer conversions that differ in unsignedness

[Mike Stump]

On Dec 5, 2005, at 9:53 AM, schopper-gcc@bfw-online.de wrote:
> 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?

Good question.  I don't believe so:

        [#5] Each of the comma-separated sets  designates  the  same
        type,  except  that  for  bit-fields,  it is implementation-
        defined whether the specifier int designates the  same  type
        as signed int or the same type as unsigned int.

[ note, I have a feeling they meant char, not int, I suspect someone  
might be able to provide a pointer to a DR for this. ]

        [#14]  The type char, the signed and unsigned integer types,
        and the floating types are  collectively  called  the  basic
        types.  Even if the implementation defines two or more basic
        types to have the same representation, they are nevertheless
        different types.29)

        [#15] The three types char, signed char, and  unsigned  char
        are   collectively   called   the   character   types.   The
        implementation shall define char to  have  the  same  range,
        representation,  and  behavior  as  either  signed  char  or
        unsigned char.30)

        30)CHAR_MIN, defined in <limits.h>, will  have  one  of  the
           values   0   or  SCHAR_MIN,  and  this  can  be  used  to
           distinguish the two options.  Irrespective of the  choice
           made,  char  is a separate type from the other two and is
           not compatible with either.


Did you find wording in the standard that mandates no diagnostic on  
the first three?