Date: Fri, 4 Aug 2017 21:55:38 -0600 From: Warner Losh <imp@bsdimp.com> To: Bruce Evans <brde@optusnet.com.au> Cc: Alan Cox <alc@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r322041 - head/sys/kern Message-ID: <CANCZdfq5VFWCBWC%2BMU-f9XkG8tP-91zafjoKx5Npew%2ByXZ-fjw@mail.gmail.com> In-Reply-To: <20170805123249.K1377@besplex.bde.org> References: <201708040423.v744NOix022999@repo.freebsd.org> <20170805123249.K1377@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 4, 2017 at 9:22 PM, Bruce Evans <brde@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq5VFWCBWC%2BMU-f9XkG8tP-91zafjoKx5Npew%2ByXZ-fjw>