From owner-svn-src-all@freebsd.org Thu Apr 21 06:01:28 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 C464AB17722; Thu, 21 Apr 2016 06:01:28 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 55738101E; Thu, 21 Apr 2016 06:01:27 +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 mail110.syd.optusnet.com.au (Postfix) with ESMTPS id 55A1E781620; Thu, 21 Apr 2016 16:01:18 +1000 (AEST) Date: Thu, 21 Apr 2016 16:01:17 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin cc: Bruce Evans , araujo@freebsd.org, "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: <17068472.zUDTmEYeVg@ralph.baldwin.cx> Message-ID: <20160421150811.K1013@besplex.bde.org> References: <201604190446.u3J4kD9G050780@repo.freebsd.org> <20160420115844.Y967@besplex.bde.org> <17068472.zUDTmEYeVg@ralph.baldwin.cx> 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=EfU1O6SC 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=97wTcub5ifeoF_xb2IAA:9 a=F8U9ZFIdhsjt1h1j:21 a=zVJKAXGHhyAhCwZx:21 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: Thu, 21 Apr 2016 06:01:28 -0000 On Wed, 20 Apr 2016, John Baldwin wrote: > On Wednesday, April 20, 2016 01:06:38 PM Bruce Evans wrote: >> On Wed, 20 Apr 2016, Marcelo Araujo wrote: >> >>> 2016-04-20 0:16 GMT+08:00 John Baldwin : >>> >>>> On Tuesday, April 19, 2016 04:46:13 AM Marcelo Araujo wrote: >>>>> Author: araujo >>>>> Date: Tue Apr 19 04:46:13 2016 >>>>> New Revision: 298247 >>>>> URL: https://svnweb.freebsd.org/changeset/base/298247 >>>>> >>>>> Log: >>>>> Remove redundant parenthesis. >>>>> >>>>> Submitted by: pfg >>>>> MFC after: 2 weeks. >> >> I don't realling like churnging to the nonstandard nitems(). Use >> of the nonstandard is bad enough. > > I think it's not that bad from a readability standpoint. Other languages > have fairly concise syntax for 'for-each' loops and this provides a > closer variant of that for statically sized arrays. TAILQ_FOREACH() is > still nicer of course. One could imagine doing some sort of > ARRAY_FOREACH() that was: Ugh, I really realling (sic) don't like the FOREACH macros. The FOREACH macros add syntactic salt. The queue macros were bad enough before they had FOREACH. Arrays don't start with such nastiness. > #define ARRAY_FOREACH(p, array) \ > for (size_t __i = 0, (p) = &(array)[0]; __i < nitems((array)); __i++, (p)++) This only works in the not very usual case of a simple loop from the start to the end. Even the name EACH becomes wrong if the range is anything else. For full nastiness, add a few hundred FORFOO macros to handle multi- dimensional arrays with different access methods, array slices, sentinels and other terminating conditions, etc. > Perhaps better is this: > > #define ARRAY_FOREACH(p, array) \ > for ((p) = &(array)[0]; (p) < &(array)[nitems((array))]; (p)++) > > (No need for __i) But hiding the indexes forces the old C programming idiom of using pointers for everything. A mere few hundred FORFOO macros won't do. For just 1-dimensional FOREACH, you need 3 versions to expose p, i or both p and i. >> Churnging too much (also remove excessive parentheses and braces) gives: >> >> size_t i; /* XXX: I don't like unsigned types, but... */ >> >> for (i = 0; i < nitems(part_types); i++) >> if (part_types[i].type == type & 0x7f) >> return (part_types[i].name); >> return ("unknown"); > > This would work for me (unless folks actually like the ARRAY_FOREACH() > idea). Once a loop is simple enough, it is easy to see that it really is simple without an ARRAY_FOREACH() macros that hides its details. Actually, it is not so simple since it has a special terminating condition. It only handles EACH (every) element in unusual cases. Bruce