On Thu, 8 Feb 2007, Jan Engelhardt wrote:
>
> Thank you for this insight, I don't usually read standards, only RFCs :)
> Uh, does that also apply to the longer types, int, long etc.? I hope not.
No. An "int" or "long" is always signed.
But bitfields, enums or "char" can - and do - have signedness that depends
on the architecture and/or compiler writers whims.
So if you do
enum my_enum {
orange = 1,
blue = 2,
green = 3
};
you don't know if "enum my_enum" is signed or not. The compiler could
decide to use "int". Or it could decide to use "unsigned char" for it. You
simply don't know.
Same goes for
struct dummy {
int flag:1;
} a_variable;
which could make "a_variable.d" be either signed or unsigned. In the
absense of an explicit "signed" or "unsigned" by the programmer, you
really won't even _know_ whether "flag" can contain the values {0,1} or
{-1,0}.
Normally you wouldn't ever even care. A one-bit bitfield would only ever
really be tested against 0, but it really is possible that when you assign
"1" to that value, and read it back, it will read back -1. Try it.
Those are the three only types I can think of, but the point is, they
really don't have any standard-defined sign. It's up to the compiler.
Now, passing a "pointer to bitfield" is impossible, and if you pass a
pointer to an enum you'd better *always* use the same enum anyway (because
not only is the signedness implementation-defined, the _size_ of the enum
is also implementation-defined), so in those two cases, -Wpointer-sign
doesn't hurt.
But in the case of "char", it really is insane. It's doubly insane exactly
because the C standard defines a lot of standard functions that take "char
*", and that make tons of sense with unsigned chars too, and you may have
100% good reasons to use "unsigned char" for many of them.
> >It really is that simple. gcc is broken. The C language isn't, it's purely
> >a broken compiler issue.
>
> Maybe you could send in a patch to gcc that fixes the issue?
I've butted heads with too many broken gcc decisions. I've occasionally
used to try to discuss these kinds of things on the gcc mailing lists, but
I got too fed up with language lawyers that said "the standard _allows_ us
to be total *ssholes, so stop complaining". It seemed to be an almost
universal defense.
(And yes, the standard allows any warnings at all. So technically, gcc can
warn about whatever hell it wants. It doesn't make it a good idea).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
