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