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! > > I'm not sure it matters much, but I suspect that as long as your fields > > aren't bigger than 32 bits, you should go for "unsigned int". This gives > > the compiler more freedom to deal with them... > > > > what if i need more than 32bits? then use unsigned long or u64 even > also for *_bit stuff, i remember somewhere states that i need to claim a > unsigned long yes that is correct > and only safely to use 24bits. does that still hold true? that is not correct. The limit of 24 bits was only for atomic_t, and has been removed in the 2.6 kernels as well, so is no longer relevant even for atomic_t. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
