On Fri, Aug 4, 2017 at 9:22 PM, Bruce Evans <b...@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 <do...@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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
