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>