Re: [Qemu-devel] [PATCH 07/10] pseries: Clean up error handling in spapr_rtas_register()

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 01/20/2016 03:53 PM, Eric Blake wrote:
> On 01/19/2016 05:21 PM, Alexey Kardashevskiy wrote:
>
>>> You could drop the redundant () while touching this, as in:
>>
>>
>> Seriously? Why? I personally find it really annoying (but I stay silent)
>> when people omit braces in cases like this.
>>
>>
>>> assert(token >= RTAS_TOKEN_BASE && token < RTAS_TOKEN_MAX);
>
> Because it's the prevailing style. I estimate that less than 10% of qemu
> over-parenthesizes, mostly because && and || are well-known C operator
> precedence:
 >
> $ git grep ' && ' | wc
>     6462   57034  482477
> $ git grep ') && (' | wc
>      578    6151   48655
>
> Of course, that's a rough estimate, as it has false positives on 'if
> (foo() && (b || c))', and false negatives on conditionals where there is
> a unary rather than binary operator on either side of &&; but I'm sure
> you could write a Coccinelle script if you wanted more accurate counting.
>
> But you are equally right that as long as HACKING doesn't document it,
> and checkpatch.pl doesn't flag it, then you can over-parenthesize binary
> arguments to the short-circuiting operators to your aesthetic tastes.

C Operator Precedence is well-known and still confusing, I cannot get used 
to the fact that </>/==/etc have higher priority than &/&&/etc so not 
seeing braces in the cases like above makes me nervous. Yes, I am sort of 
retarded :(

So, we can keep doing this over-parenthesizing, good, thanks :)

> And for other operators, like '&' and '|', I definitely recommend the
> parenthesis, particularly if you manage to trigger a gcc or clang
> warning (in spite of the precedence being unambiguous) if you omit the
> parenthesis.

Goood.


-- 
Alexey