On 6/5/07, Roman Shaposhnick <[EMAIL PROTECTED]> wrote:
On Tue, 2007-06-05 at 17:36 -0700, ron minnich wrote: > /* catch the bug */ > > struct x { > int botch:1; > }; > > fun(){ > struct x x; > x.botch = 0; > x.botch = 1; > } > > ok, what's the bug? anyone? I just found this out today. (no, I don't > use bitfields, but insane people do)signed vs. unsigned int perhaps (meaning that x.botch becomes < 0 after the last assignment) ?
yeah. x.botch is 0 after last assignment. Until recently, gcc would give you dispensation and set x.botch to -1 anyway if you set x.botch = 1. But, recently, it now figures out it's an overflow and sets x.botch to 0. So, lots of code all over the place will now do the unexpected, in reverse of what it used to do. It's interesting to watch. This change evidently broke much code. So folks are chasing down their assignments all over the place, catching up with the change. Just saw this going by the Xen list. Bitfields are another story. People really love 'em in some parts of this universe. ron
