From owner-svn-src-head@freebsd.org Sat Aug 5 03:45:49 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DAF6ADB55AF; Sat, 5 Aug 2017 03:45:49 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id A35703C6D; Sat, 5 Aug 2017 03:45:49 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id F3428D43442; Sat, 5 Aug 2017 13:22:10 +1000 (AEST) Date: Sat, 5 Aug 2017 13:22:10 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alan Cox cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r322041 - head/sys/kern In-Reply-To: <201708040423.v744NOix022999@repo.freebsd.org> Message-ID: <20170805123249.K1377@besplex.bde.org> References: <201708040423.v744NOix022999@repo.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VbSHBBh9 c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=DUQRlfxLKrqfm2yATDEA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 03:45:50 -0000 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 > 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