From: dscott AT networkusa DOT net (SCOTT19U.ZIP_GUY) Newsgroups: comp.os.msdos.djgpp Subject: Re: A bug in DJGPP? (length of bit fields) Date: Thu, 30 Dec 1999 21:03:23 GMT Organization: Retired Electronic Engineer and Y2K expert Lines: 125 Message-ID: <84gdqg$29fi$1@news.gate.net> References: <84fmpj$ptf$1 AT newsg3 DOT svr DOT pol DOT co DOT uk> NNTP-Posting-Host: ppp-30.elpasonet.net X-Trace: news.gate.net 946584208 75250 216.84.6.59 (30 Dec 1999 20:03:28 GMT) X-Complaints-To: abuse AT gate DOT net NNTP-Posting-Date: 30 Dec 1999 20:03:28 GMT X-Newsreader: News Xpress 2.01 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com In article <84fmpj$ptf$1 AT newsg3 DOT svr DOT pol DOT co DOT uk>, "Mike Collins" wrote: >Good folks of the DJGPP community, > >Firstly, I have read the FAQ, and I do not believe the answer to this >question to be there. > >I am aware that part-words in structures tend to get padded out to word >boundaries, so, for example, a short int may get padded out to 4 bytes, even >though only two bytes are used for its quantity. I have come across a case, >however, where bit-field variables seem to be being rounded DOWN. > >Please look at the short program below, and read the comments on the >structures. >I declared six structures, and wrote a comment line against each of them, >showing what I expected the length of the structure to be. >Then, I compiled and executed the program, and used the results to write a >further comment on each structure to show its actual size as measured by >'sizeof'. >Note that TEST2, TEST3 and TEST6 have actual sizes that are smaller than >expected, and seem to have been rounded DOWN. TEST6 clearly shows two >unsigned integers being put into 4 bytes. > >Is this not a bug? I would not call it a bug. Why does it have to fit in what you want. The C standard is pretty flexable so that various code can ran fast on different machines. There are lots of way to force it to do something different. If you are doing something that actaully depends on the hardware locations you should always write test code to see how it lays it out. And yes new versions of the compiler may do it differently as do the different manufactures of compilers for the same machine. I would call it a bug if you can't read or write to the fields. How it packs it is something one must play with. To see a program with lots of fields look at scott19u.zip I use fileds all over the place. > >Mike Collins. > >#include > >struct TEST1 >{ unsigned bit_field_1 : 8, // expected : 4 bytes (32 bits unsigned) > bit_field_2 : 8; // actual : 4 >}; > >struct TEST2 >{ short s; > unsigned bit_field_1 : 8, // expected : 8 (16 bits short + 16 bits >padding > bit_field_2 : 8; // + 32 bits unsigned) >}; // actual 4 > >struct TEST3 >{ unsigned bit_field_1 : 8, // expected : 6 (32 bits unsigned + 16 bits >short > bit_field_2 : 8; // actual : 4 > short s; >}; > >struct TEST4 >{ unsigned bit_field_1 : 8, // expected : 4 (32 bits unsigned) > bit_field_2 : 8, // actual : 4 > bit_field_3 : 1; >}; > >struct TEST5 >{ unsigned bit_field_1 : 8, // expected : 6 (32 bits unsigned + 16 bits >short > bit_field_2 : 8, // actual : 8 > bit_field_3 : 1; // Why is this different from TEST3 ? > short s; >}; > >struct TEST6 >{ unsigned bit_field_1 : 8, // expected : 8 (32 bits unsigned > bit_field_2 : 8; // + 32 bits unsigned) > unsigned bit_field_3 : 8, // actual : 4 !! > bit_field_4 : 8; >}; > >main() >{ struct TEST1 test1; > struct TEST2 test2; > struct TEST3 test3; > struct TEST4 test4; > struct TEST5 test5; > struct TEST6 test6; > cprintf("\r\nSize of test1 = %d", sizeof(test1)); > cprintf("\r\nSize of test2 = %d", sizeof(test2)); > cprintf("\r\nSize of test3 = %d", sizeof(test3)); > cprintf("\r\nSize of test4 = %d", sizeof(test4)); > cprintf("\r\nSize of test5 = %d", sizeof(test5)); > cprintf("\r\nSize of test6 = %d", sizeof(test6)); > } > >Results of running the program : > >Size of test1 = 4 >Size of test2 = 4 >Size of test3 = 4 >Size of test4 = 4 >Size of test5 = 8 >Size of test6 = 4 > > David A. Scott -- SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE http://www.jim.com/jamesd/Kong/scott19u.zip Scott famous encryption website NOT FOR WIMPS http://members.xoom.com/ecil/index.htm Scott rejected paper for the ACM http://members.xoom.com/ecil/dspaper.htm Scott famous Compression Page WIMPS allowed http://members.xoom.com/ecil/compress.htm **NOTE EMAIL address is for SPAMERS*** I leave you with this final thought from President Bill Clinton: "The road to tyranny, we must never forget, begins with the destruction of the truth."