From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Martin v. Loewis" To: greened@eecs.umich.edu Cc: egcs@egcs.cygnus.com Subject: Re: egcs and bitfields Date: Wed, 31 Mar 1999 23:46:00 -0000 Message-ID: <199903121718.SAA09252@mira.isdn.cs.tu-berlin.de> References: <36E844B2.8DAEFAAF@eecs.umich.edu> <199903112300.AAA19947@mira.isdn.cs.tu-berlin.de> <36E92F61.5951621@eecs.umich.edu> X-SW-Source: 1999-03n/msg00465.html Message-ID: <19990331234600.rkRbdz2F3dTJa6WkBU692T-7hSHD_SHxmMVhEW9btMQ@z> > #include > > 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