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 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 ;) > 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 -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
