From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1qYh-0001hu-QA for qemu-devel@nongnu.org; Sat, 02 Feb 2013 22:48:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U1qYg-0001f0-O6 for qemu-devel@nongnu.org; Sat, 02 Feb 2013 22:47:59 -0500 Received: from mail-wi0-f176.google.com ([209.85.212.176]:58871) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U1qYg-0001ew-Gy for qemu-devel@nongnu.org; Sat, 02 Feb 2013 22:47:58 -0500 Received: by mail-wi0-f176.google.com with SMTP id hm14so1843594wib.9 for ; Sat, 02 Feb 2013 19:47:57 -0800 (PST) Sender: Paolo Bonzini Message-ID: <510DDDE8.7030408@redhat.com> Date: Sun, 03 Feb 2013 04:47:52 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1359756196-5588-1-git-send-email-pbonzini@redhat.com> <510D2C94.2010605@redhat.com> In-Reply-To: <510D2C94.2010605@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3] bitops: unify bitops_ffsl with the one in host-utils.h, call it bitops_ctzl List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: blauwirbel@gmail.com, Peter Maydell , qemu-devel@nongnu.org, sw@weilnetz.de Il 02/02/2013 16:11, Eric Blake ha scritto: > On 02/02/2013 06:30 AM, Peter Maydell wrote: > >>> - * 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). > > Yes, Paolo's code was replacing: > > ffsl(var) - 1 > > with > > bitops_ctzl(var) > > where var==0 was a definite possibility, so we DO have code that depends > on this semantic of returning -1. Actually I'm pretty sure that var == 0 is not possible in hbitmap. But I still prefer having total functions, and also keeping the function monotonic. For example, I would use the number of bits in word for clz(0), since clz(x) is monotonic decreasing. Paolo >> 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] > > For all non-zero values of var, ffsl(var) == bitops_ctzl(var)+1. > Extending the equivalency for var==0 makes the function usable in the > most places. >