From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <13426df10706052041x516117f0sf873a56ed5c05b94@mail.gmail.com>
Date: Tue,  5 Jun 2007 20:41:54 -0700
From: "ron minnich" <rminnich@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] quiz
In-Reply-To: <1181090589.4241.41.camel@work.sfbay.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <13426df10706051736q4e1852a9g3f54d8f6e2d182b4@mail.gmail.com>
	<1181090589.4241.41.camel@work.sfbay.sun.com>
Topicbox-Message-UUID: 79be2004-ead2-11e9-9d60-3106f5b1d025

On 6/5/07, Roman Shaposhnick <rvs@sun.com> 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