lkml.org 
[lkml]   [2008]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Problem with find_first_bit function and kin



--- On Sun, 8/17/08, Alexander van Heukelum <heukelum@fastmail.fm> wrote:

> From: Alexander van Heukelum <heukelum@fastmail.fm>
> Subject: Re: Problem with find_first_bit function and kin
> To: oakad@yahoo.com, "Linux kernel mailing list" <linux-kernel@vger.kernel.org>
> Date: Sunday, August 17, 2008, 4:58 AM
> On Sat, 16 Aug 2008 12:26:54 -0700 (PDT), "Alex
> Dubov" <oakad@yahoo.com>
> said:
> > It's well may be that I'm just missing
> something obvious.
> >
> > It seems to me that find_first_bit/find_next_bit
> functions return their
> > offsets "base 1" - first set bit is
> "1" and last is "bitmap size". This
> > means that if only the last bit in the bitmap is set,
> the returned value
> > will be indistinguishable from no bits set situation.
> Moreover, bit
> > manipulation functions appear to use "base
> 0" bit addresses, adding to
> > the
> > inconvenience.
> >
> > Is this a desired behavior? And, if yes, how is one
> supposed to deal with
> > last bit of the bitmap?
>
> Hi Alex,
>
> If this is the behaviour you observe, it's a bug. How
> did you
> find out?
>
> The intended behaviour is that the bits are enumerated in
> "base 0"
> style. If only the last bit in the bitmap is set it should
> return
> bitmapsize-1 and if no bit is set it should return
> bitmapsize.
> Some architecture-specific code gets the last detail wrong,
> they
> return a value that is slightly larger than the bitmap size
> in
> some cases.
>
> Greetings,
> Alexander
> --

I was compiling some stuff out-of-the tree and got "ffs" linked in instead
of "__ffs", which caused all this weird behavior (on 64b platform). Sorry
for the noise.

But then, why "ffs" behaves differently from "__ffs" and whats the reason
they both exist?






\
 
 \ /
  Last update: 2008-08-18 04:39    [W:0.037 / U:0.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site