Re: use bit field or kernel *_bit()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

so the tricky question is what if i only have 1 bit? will that bit be
sign bit and no data bit at all?

i DO have a code here that use int and many bit field are foo:1. code
runs ok.


> 
> > > 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.

o, yes it was for atomic_t, not for *_bit stuff.

thanks for this. i recall that i read that from LDD2, so I need to check
LDD3 again.


> 
> 


--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux