Re: egcs and bitfields

["Martin v. Loewis" <martin at mira dot isdn dot cs dot tu-berlin dot de>]

> #include <stdio.h>
> 
> struct foo { int c:3; } x = { 7 };
> 
> int main(void)
> {
>   printf("%d\n", x.c);
> 
>   return(0);
> }

Ok, I can reproduce this printing -1. Yet, it still took me a while to
understand the problem. If you had provided proper references and
quotes, that would have been nice... Here's what I found:

The C standard explicitly leaves it unspecified whether an int
bitfield is signed or unsigned. In draft C9x, 6.7.2/5 says

>> 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.

Now, the gcc documentation says, in the command-line-flags section,

`-fsigned-bitfields'
`-funsigned-bitfields'
`-fno-signed-bitfields'
`-fno-unsigned-bitfields'
     These options control whether a bitfield is signed or unsigned,
     when the declaration does not use either `signed' or `unsigned'.
     By default, such a bitfield is signed, because this is consistent:
     the basic integer types such as `int' are signed types.

     However, when `-traditional' is used, bitfields are all unsigned
     no matter what.

Indeed, when I compile your program with -funsigned-bitfields, it
gives the output '7', on i586-pc-linux-gnu.

Please have a look at the section 'Non-bugs' in the GCC manual. It
explains, in an elaborate way, why things are the way they are (and
yes, I've read this section for the first time today :-)

If you still think there is a bug, please make a detailed report to
egcs-bugs@cygnus.com. I think in this case, such a report should also
go to gcc-bugs@gnu.org.

Regards,
Martin