qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 2/5] CODING_STYLE: add C type rules


From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [PATCH 2/5] CODING_STYLE: add C type rules
Date: Wed, 18 Aug 2010 19:55:14 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Thunderbird/3.1.1

 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.




reply via email to

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