Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Aug 2017 13:22:10 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Alan Cox <alc@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org,  svn-src-head@freebsd.org
Subject:   Re: svn commit: r322041 - head/sys/kern
Message-ID:  <20170805123249.K1377@besplex.bde.org>
In-Reply-To: <201708040423.v744NOix022999@repo.freebsd.org>
References:  <201708040423.v744NOix022999@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170805123249.K1377>