Ricardo M. Correia spotted that the use of __fls() in fls64() did not seem to make sense. In fact fls64()'s implementation is fine, but the description of __fls() was wrong. Fix that. Reported-by: "Ricardo M. Correia" <Ricardo.M.Correia@xxxxxxx> Signed-off-by: Alexander van Heukelum <heukelum@xxxxxxxxxxx> --- On Sat, Jul 05, 2008 at 05:56:37PM +0100, Ricardo M. Correia wrote: > Hi, > > I have a question about fls64() which I hope you or someone else could > clarify, please see below. > > On Sáb, 2008-03-15 at 18:32 +0100, Alexander van Heukelum wrote: > > +#elif BITS_PER_LONG == 64 > > +static inline int fls64(__u64 x) > > +{ > > + if (x == 0) > > + return 0; > > + return __fls(x) + 1; > > +} > > It seems fls64() is implemented on top of __fls(), however the __fls() > implementation on the x86-64 architecture states that the result is > undefined if the argument does not have any zero bits. You have found a bug. It's not in fls64, though, but a copy/paste one in the comment preceding __fls(). __fls() gives an undefined result if there are no _set_ bits: only __fls(0) gives an undefined result. The inconsistency is well-spotted, though, thanks. Patch is against current -tip. Greetings, Alexander > So if I understand correctly, the statement "fls64(~0ULL)" would return > an undefined result on x64-64 instead of 64 as one would expect. > > Wouldn't it make sense to check for ~0ULL in fls64()? > > Thanks, > Ricardo --- diff --git a/include/asm-x86/bitops.h b/include/asm-x86/bitops.h index 96b1829..cfb2b64 100644 --- a/include/asm-x86/bitops.h +++ b/include/asm-x86/bitops.h @@ -356,7 +356,7 @@ static inline unsigned long ffz(unsigned long word) * __fls: find last set bit in word * @word: The word to search * - * Undefined if no zero exists, so code should check against ~0UL first. + * Undefined if no set bit exists, so code should check against 0 first. */ static inline unsigned long __fls(unsigned long word) { -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html