From owner-svn-src-all@freebsd.org Wed Apr 20 15:15:29 2016 Return-Path: Delivered-To: svn-src-all@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 087A5B1665B; Wed, 20 Apr 2016 15:15:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 96A551152; Wed, 20 Apr 2016 15:15:28 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c110-21-41-193.carlnfd1.nsw.optusnet.com.au (c110-21-41-193.carlnfd1.nsw.optusnet.com.au [110.21.41.193]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 3003AD62CAF; Thu, 21 Apr 2016 01:15:18 +1000 (AEST) Date: Thu, 21 Apr 2016 01:15:18 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Conrad Meyer cc: Pedro Giffuni , Bruce Evans , araujo@freebsd.org, John Baldwin , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r298247 - head/sbin/fdisk_pc98 In-Reply-To: Message-ID: <20160421004457.L1073@besplex.bde.org> References: <201604190446.u3J4kD9G050780@repo.freebsd.org> <4114217.PtcV9LDMal@ralph.baldwin.cx> <20160420115844.Y967@besplex.bde.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.1 cv=TuMb/2jh c=1 sm=1 tr=0 a=73JWPhLeruqQCjN69UNZtQ==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=3oYkN2nUbJYVCEAYZf8A:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 15:15:29 -0000 On Wed, 20 Apr 2016, Conrad Meyer wrote: > On Wed, Apr 20, 2016 at 7:33 AM, Pedro Giffuni wrote: >> One of the things I dislike is that most of the macros are in >> lowercase. Lowercase would make sense if these were inline functions >> but inline functions have disadvantages for these use cases. >> OTOH, if they were uppercase, they would not be very easy on the eyes, >> which is the current advantage. Lower case is correct if nitems is a safe macro. I think it is safe, because its parameter must be an array and an expression with side effects can't be an array. > You bring up a good point. Obviously nitems() can't be an inline > function, but roundup2() and friends could. Is there any reason not > to change them over to inline functions? 1. Namespace pollution. Adding nitems() to sys/param.h already broke anything using that name. 2. roundup2() and friends can't be inline functions without unportable complications to make them type-generic. No one ever did this for the more important imin() family of inline functions. 4.4BSD removed the MAX() and MIN() macros in the kernel to enforce use of the imin() family, but this gave type errors and was routed around by restoring the macros, first in scattered places and then back in sys/param.h. 2-arg type-generic functions are especially difficult since they have N^2 combinations where N is approximately the number of types in inttypes.h. There are 8 basic types just for 8/16/32/64 bits signed and unsigned. For compaibility, the result type must be the same as what the macro gives. Bruce