From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43181 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OllvB-0005nY-A0 for qemu-devel@nongnu.org; Wed, 18 Aug 2010 12:55:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ollv7-0000g1-QA for qemu-devel@nongnu.org; Wed, 18 Aug 2010 12:55:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22829) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ollv7-0000ft-Id for qemu-devel@nongnu.org; Wed, 18 Aug 2010 12:55:21 -0400 Message-ID: <4C6C1072.1000200@redhat.com> Date: Wed, 18 Aug 2010 19:55:14 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2/5] CODING_STYLE: add C type rules References: <4C6A43B5.40809@redhat.com> <4C6AD744.1070009@twiddle.net> <4C6B9B44.7020803@redhat.com> <4C6BB642.4000205@redhat.com> <4C6BE6E1.9010108@redhat.com> In-Reply-To: <4C6BE6E1.9010108@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Blue Swirl , qemu-devel@nongnu.org, Jes Sorensen On 08/18/2010 04:57 PM, Paolo Bonzini wrote: > On 08/18/2010 12:30 PM, Kevin Wolf wrote: >> Am 18.08.2010 10:35, schrieb Paolo Bonzini: >>> On 08/17/2010 08:39 PM, Richard Henderson wrote: >>>>> On 08/12/10 19:50, Blue Swirl wrote: >>>>>> +While using "bool" is good for readability, it comes with >>>>>> minor caveats: >>>>>> + - Don't use "bool" in places where the type size must be >>>>>> constant across >>>>>> + all systems, like public interfaces and on-the-wire protocols. >>>>>> + - Don't compare a bool variable against the literal, "true", >>>>>> + since a value with a logical non-false value need not be "1". >>>>>> + I.e., don't write "if (seen == true) ...". Rather, write >>>>>> "if (seen)...". >>>>> >>>>> I'd strongly discourage the use of bool in any code. >>>> >>>> I strongly disagree. The use of "bool", even if you ignore stdbool.h >>>> and do "typedef int bool", is valuable documentation in the code. >>> >>> I think "bool" is fine, but it should be either stdbool.h or a typedef. >>> Using stdbool.h only when it is present is going to introduce >>> bugs the >>> day someone relies on the magic properties of the C99 bool. >> >> We rely on C99 anyway, so stdbool.h should always be present (and in >> fact, it is used unconditionally today). > > Right. However, this is wrong then: > > - Don't compare a bool variable against the literal, "true", > since a value with a logical non-false value need not be "1". > I.e., don't write "if (seen == true) ...". Rather, write "if > (seen)...". > > I mean, I'm all for using "if (seen)" but bool *does* normalize > logical non-false values to "1". I'd remove the second line (making > it just a coding style issue) and add something like this: > > - Do not rely on the fact that bool normalizes logical non-false values > to 1. So, write "x = true" instead of "x++" and "x = !x" instead of > "x--". > - Similarly, when x is a bool, it may be clearer to avoid > "x |= y". Instead, use either "x = x || y" (if short circuiting > is acceptable or even desirable) or "x |= (y != 0)". > > Probably a bit too verbose, but you get the idea. _Bool can have values of 0 or 1, so all of the above should actually work. _Bool convert_to_bool(long long x) { return x; } 0: 48 85 ff test %rdi,%rdi 3: 0f 95 c0 setne %al 6: c3 retq void incr(_Bool* b) { ++*b; } 10: c6 07 01 movb $0x1,(%rdi) 13: c3 retq If _Bool were int, the first example would fail. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.