qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3] bitops: unify bitops_ffsl with the one in ho


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v3] bitops: unify bitops_ffsl with the one in host-utils.h, call it bitops_ctzl
Date: Sat, 2 Feb 2013 13:30:25 +0000

On 1 February 2013 22:03, Paolo Bonzini <address@hidden> wrote:
> We had two copies of a ffs function for longs with subtly different
> semantics and, for the one in bitops.h, a confusing name: the result
> was off-by-one compared to the library function ffsl.
>
> Unify the functions into one, and solve the name problem by calling
> the 0-based functions "bitops_ctzl" and "bitops_ctol" respectively.
>
> This also fixes the build on platforms with ffsl, including Mac OS X
> and Windows.
>
> Signed-off-by: Paolo Bonzini <address@hidden>

Tested-by: Peter Maydell <address@hidden>

This fixes the MacOSX build failure and boots a guest OK.

>  /**
> - * bitops_ffs - find first bit in word.
> + * bitops_ctzl - count trailing zeroes in word.
>   * @word: The word to search
>   *
> - * Undefined if no bit exists, so code should check against 0 first.
> + * Returns -1 if no bit exists.  Note that compared to the C library
> + * routine ffsl, this one returns one less.
>   */

Do any of our callers actually use the "-1 on 0 input" semantics?
(I guess that means "your new code you added" since the previous
callers all were happy with the undefined-on-zero semantics).
It seems an odd choice, since I can see a justification for:
 (a) "return number of bits in word" [every bit in the word is
     a trailing zero in some sense]
 (b) "undefined" [matches gcc builtin_ctz semantics]

However I'm more interested in getting a reasonable patch
for the build issues committed before the next rc rather
than spending too much time nitpicking details.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]