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

[Avi Kivity <avi@redhat.com>]

  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.