svn commit: r322041 - head/sys/kern

[Warner Losh]

On Fri, Aug 4, 2017 at 9:22 PM, Bruce Evans <brde at optusnet.com.au> wrote:

> On Fri, 4 Aug 2017, Alan Cox wrote:
>
> Log:
>>  In case readers are misled by expressions that combine multiplication and
>>  division, add parentheses to make the precedence explicit.
>>
>>  Submitted by:  Doug Moore <dougm at rice.edu>
>>  Requested by:  imp
>>  Reviewed by:   imp
>>  MFC after:     1 week
>>  X-MFC after:   r321840
>>  Differential Revision: https://reviews.freebsd.org/D11815
>>
>
> This obfuscates the necessary parentheses.
>
> Modified: head/sys/kern/subr_blist.c
>> ...
>> static inline daddr_t
>> radix_to_skip(daddr_t radix)
>> {
>>
>>         return (radix /
>> -           (BLIST_BMAP_RADIX / BLIST_META_RADIX * (BLIST_META_RADIX -
>> 1)));
>> +           ((BLIST_BMAP_RADIX / BLIST_META_RADIX) * (BLIST_META_RADIX -
>> 1)));
>> }
>>
>
> Readers now have to do a more complete parse to find the interesting parts,
> and writers have to count to a large number to get the count right when
> the parantheses pile up at the right.
>
> This expression is relatively simple to parse to remove the obfuscation,
> but consider more complicated cases:
>
> (1)
>         (a + b + c + d + e) + (f + g + h + i + j)
>
> in floating point so that addition is not associative and the order
> matters.
> The order is left to right in C, and this expression uses 2 sets of
> parentheses to not use left to right for all terms.  Full parentheses gives
> the good obfuscation:
>
>         ((((a + b) + c) + d) + e) + ((((f + g) + h) + i) + j)
>
> (2) Similarly with +- instead of all +.  The order matters much more, but I
> don't remember ever seeing expressions with only +- being obfuscated by
> parentheses, except in floating point code where the author wants to
> emphasize the left to right evaluation.  I guess there are also examples
> with integer types.  Even with all + operations, the order is critical
> with plain ints, since different orders might cause overflow, and with
> mixed signed/unsigned/small/large integer types, the promotions depend
> on the order.
>
> (3) Similarly with */ instead of +-.  These are even more similar in
> programming uses than in math structures, since + is always associative
> and commutative in math structures, but it is not even commutative in
> programming.


You know, for this case, it's totally cool.

Warner