On Thu, 8 Feb 2007, David Rientjes wrote:
>
> Your struct:
>
> struct dummy {
> int flag:1;
> } a_variable;
>
> should expect a_varible.flag to be signed, that's what the int says.
No it's not.
You just don't understand the C language.
And if you don't understand the C language, you can't say "that's what the
int says". It says no such thing.
The C language clearly says that bitfields have implementation-defined
types. So when you see
struct dummy {
int flag:1;
} a_variable;
if you don't read that as "oh, the sign of 'flag' is implementation-
defined", then you simply aren't reading it right.
Is it "intuitive"? Nobody ever really called C an _intuitive_ language. C
has a lot of rules that you simply have to know. The bitfield sign rule is
just one such rule.
> There is no special case here with regard to type.
Sure there is. Read the spec.
I don't understand why you are arguing. YOU ARE WRONG.
Bitfields simply have implementation-defined signedness. As do enums. As
does "char". It really is that simple.
The *real* special case is actually "int" and "long". In many ways, the
fact that those *do* have a well-specified signedness is actually the
exception rather than the rule.
Most C types don't, and some you can't even tell (do pointers generate
"signed" or "unsigned" comparisons? I'll argue that a compiler that
generates signed comparisons for them is broken, but it tends to be
something you can only see with a standards- conforming proghram if you
can allocate memory across the sign boundary, which may or may not be
true..)
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
