[9fans] quiz

[9fans] quiz

[ron minnich]

/* 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)

ron

Re: [9fans] quiz

[Roman Shaposhnick]

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) ?

Thanks,
Roman.

Re: [9fans] quiz

[ron minnich]

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

Re: [9fans] quiz

[Roman Shaposhnik]

On Tue, 2007-06-05 at 20:41 -0700, ron minnich wrote:
> >   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.

  Nice! That's an unexpected twist I must admit ;-) What version of
gcc does this?

Thanks,
Roman.

Re: [9fans] quiz

[ron minnich]

On 6/5/07, Roman Shaposhnik <rvs@sun.com> wrote:

>   Nice! That's an unexpected twist I must admit ;-) What version of
> gcc does this?

I forget the exact version but it's the newer 4.x bits.

I wonder what kenc does :-)
Have not had a chance to try it.
Anyway, this whole note is more for amusement value than anything else.

ron

Re: [9fans] quiz

[Kris Maglione]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On Tue, Jun 05, 2007 at 09:18:37PM -0700, ron minnich wrote:
> I wonder what kenc does :-)

i
#include <u.h>
#include <libc.h>

struct {
	int x:1;
} foo;

void
main(void) {
	foo.x = 1;
	print("foo.x: %d\n", foo.x);
	exits(0);
}
.
w
test.c: #134
!8c test.c && 8l test.8
!
!./8.out
foo.x: -1
!

-- 
Kris Maglione

The usefulness of any meeting
is in inverse proportion to the attendance.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] quiz

[Kris Maglione]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

On Wed, Jun 06, 2007 at 12:30:55AM -0400, Kris Maglione wrote:
> !8c test.c && 8l test.8
> !
> !./8.out
> foo.x: -1
> !

Also:

!8c -wF test.c && 8l test.8
warning: test.c:11 format mismatch d LONG 0:1, arg 2
!

I'm surprised that there's not a warning about the overflow.

-- 
Kris Maglione

For every human problem, there is a neat, plain solution --
and it is always wrong.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] quiz

[Bruce Ellis]

easy.  ken had (has) no respect for bitfields.
he is a wise man.

brucee

On 6/6/07, Kris Maglione <bsdaemon@comcast.net> wrote:
> On Wed, Jun 06, 2007 at 12:30:55AM -0400, Kris Maglione wrote:
> > !8c test.c && 8l test.8
> > !
> > !./8.out
> > foo.x: -1
> > !
>
> Also:
>
> !8c -wF test.c && 8l test.8
> warning: test.c:11 format mismatch d LONG 0:1, arg 2
> !
>
> I'm surprised that there's not a warning about the overflow.
>
> --
> Kris Maglione
>
> For every human problem, there is a neat, plain solution --
> and it is always wrong.
>
>

Re: [9fans] quiz

[W B Hacker]

Kris Maglione wrote:
> On Wed, Jun 06, 2007 at 12:30:55AM -0400, Kris Maglione wrote:
>> !8c test.c && 8l test.8
>> !
>> !./8.out
>> foo.x: -1
>> !
>
> Also:
>
> !8c -wF test.c && 8l test.8
> warning: test.c:11 format mismatch d LONG 0:1, arg 2
> !
>
> I'm surprised that there's not a warning about the overflow.
>

C *requires* the ability to create overflow situations w/o warning either by
accident, design, or randomly. Job security bureau dictate AFAIK.

What other 'feature' has been so steadfastly preserved?

Just wouldn't be 'C' without overflows...

Bill

Re: [9fans] quiz

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Signed bit field overflow.

You (don't) want "unsigned int botch:1;"

Yuck.

On 5-Jun-07, at 5:36 PM, 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)
>
> ron

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGZgi1pJeHo/Fbu1wRAk8AAJ9GjwNz6JLxWav33huG68SjB4R1YACfZHNI
BtIRBQPaXw91oj5Am+VDVaU=
=Ai0G
-----END PGP SIGNATURE-----

Re: [9fans] quiz

[Roman Shaposhnick]

On Tue, 2007-06-05 at 18:07 -0700, Paul Lalonde wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Signed bit field overflow.
>
> You (don't) want "unsigned int botch:1;"
>
> Yuck.

  This bit of C is even more obscure. Consider this:

  struct {
    enum {A=-1} x:1;
  } s = {A};

  In this particular case you're at a total mercy of
  the compiler 'cause you can't really write '[un]signed enum'

Thanks,
Roman.

[9fans] Re: quiz

[prem]

http://publications.gbdirect.co.uk/c_book/chapter6/bitfields.html
I found this very interestnig... and discuss the signed ness in a bit
field