On Fri, 8 Jan 2016, Martin Sebor wrote:
> > Signedness of char (and of bit-fields) is a tristate, "signed", "unsigned"
> > and "". My claim is that a difference between any two of those three
> > values is essentially the same kind of difference. And so at most the
> > wording should be adjusted (or maybe an inform ("%<char%> and %<signed
> > char%> are different types" added), not the conditions for some such
> > warning to be given.
>
> This explanation isn't grounded in the C definition of the types
> (which is fine if you want to use some other definition of
> "signedness").
>
> In C, plain char type is neither a signed nor an unsigned integer
> type, whether or not it has a sign bit. It's a distinct type that's
Exactly. "signed type", "unsigned type" and "type that is neither signed
nor unsigned" are the three cases in the tristate. ("type that is both
signed and unsigned" doesn't exist.)
The point of this warning is that there are certain cases of incompatible
types that are less serious than others - namely, those where the only
aspect of the type that is different is its signedness. Those get a more
specific warning, which is given under more restrictive conditions.
ISO C specifically envisages such differences as being less serious when
it allows variation between pointers to character types and void when
passing arguments to unprototyped functions.
> However, this definition of signedness would imply that the
> warning should not be issued for the code below (for example)
> when int and long have the same size, representation, and
> alignment:
>
> int *p = (long*)0;
And of course the signedness warning isn't issued - the other generic
warning about incompatible types is issued, because this is one of the
more serious cases of incompatibility, where there is a difference other
than signedness.
--
Joseph S. Myers
jos...@codesourcery.com
