Re: somebody dropped a (warning) bomb

[Linus Torvalds]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/