On Wed, 2006-03-01 at 16:11 +0100, Arjan van de Ven wrote: > On Wed, 2006-03-01 at 09:57 -0500, Ming Zhang wrote: > > On Wed, 2006-03-01 at 15:48 +0100, Arjan van de Ven wrote: > > > On Wed, 2006-03-01 at 09:38 -0500, Ming Zhang wrote: > > > > On Wed, 2006-03-01 at 15:29 +0100, Arjan van de Ven wrote: > > > > > > > > > > > > one more question, for bit field, if we use long xyz:n, will that be an > > > > > > issue in 32/64bit arch? i feel no, just to make sure. > > > > > > > > > > first of all, you almost always want to make the bitfield an "unsigned" > > > > > type; either "unsigned int" or "unsigned long". (there are exceptions to > > > > > this, but if you need them you should ask yourself if you really really > > > > > want bitfields in that case) > > > > > > > > why unsigned int will have difference from signed int? i always access > > > > it by bits right? > > > > > > NO! it will make the BITFIELD signed. Which means if you have a 3 bit > > > bitfield, the top bit of the three will be the sign bit; which is most > > > likely not what you want! > > > > ok, so my understanding is wrong, i assumed if i have > > > > int foo1:3; > > int foo2:3; > > > > compile will use a int (32bit) to hold foo1 and foo2, and each use 3bits > > (MSB or LSB not sure. depends on arch). so this is not the case? > > yup that's not the case so the case is that it will use int for each bit field? > > > > so the tricky question is what if i only have 1 bit? will that bit be > > sign bit and no data bit at all? > > yes well but remember that "-1" and "1" have the same representation in > "signed 1 bit" binary in 2's complement systems. So you've been pure > lucky ;) o, yes. so here 1 bit or 2 bits will get same data range. :P i am lucky. :P > > > > i DO have a code here that use int and many bit field are foo:1. code > > runs ok. > > I'd suggest you change that to unsigned int... the tricky part is when > you start using < and > and such > agree, must be crazy when debug bug like that! thanks! -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
