From owner-svn-src-head@freebsd.org Wed Dec 30 00:08:27 2015 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 B3978A55851; Wed, 30 Dec 2015 00:08:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7B04912AA; Wed, 30 Dec 2015 00:08:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 159E73C7721; Wed, 30 Dec 2015 10:48:16 +1100 (AEDT) Date: Wed, 30 Dec 2015 10:48:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin cc: Warner Losh , src-committers , svn-src-head@freebsd.org, svn-src-all@freebsd.org, Warner Losh Subject: Re: svn commit: r292809 - head/lib/libc/stdio In-Reply-To: <2345870.SHMMVrpc1D@ralph.baldwin.cx> Message-ID: <20151230102454.P1079@besplex.bde.org> References: <201512272304.tBRN4C5D034464@repo.freebsd.org> <41508412.yspAtSoPCD@ralph.baldwin.cx> <2345870.SHMMVrpc1D@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=PfoC/XVd c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=QuU-y7UVB-eSIWs7EHUA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 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: Wed, 30 Dec 2015 00:08:27 -0000 On Tue, 29 Dec 2015, John Baldwin wrote: > On Monday, December 28, 2015 01:01:26 PM Warner Losh wrote: >> I'll look at that, but I don't think posix_memalign is the right way to go. >> The alignment of FILE is more strict than posix_memalign will return. Ian's >> idea of __alignof__ is the way to go. We allocate them in one block on >> purpose for performance, and posix_memalign would be a one at a time affair. > > posix_memalign gives you whatever alignment you ask for. Using __alignof__ > to determine the alignment instead of hardcoding sizeof(int64_t) would > certainly be an improvement. If you move the glue after the FILE objects > then you can use posix_memalign() directly as so: > > void *mem; > int error; > > error = posix_memalign(&mem, MAX(ALIGNBYTES, __alignof__(mbstate_t)), > n * sizeof(FILE) + sizeof(*g)); Using __alignof__() involves 2 or 3 layers of style bugs: - it is a gnu-ish spelling (full gnu would also have a space before the left parentheses). The FreeBSD spelling is __alignof(). FreeBSD defines a macro for this, but only for compatiblity with gcc < 2.95. Later versions apparently support both __alignof and __alignof__() - C++ apparently spells this as both _Alignof() and alignof() after 2011/03 - FreeBSD defines _Alignof() unconditionally. The only difference for C++ after 2011/03 is it is less careful about namespaces and depends on alignof() existing and being part of the language. The general definition using __alignof() should work in this case too. So it seems that the correct spelling is _Alignof(). _Alignof(), __alignof() and __alignof__() are all in the implementation namespace except possibly _Alignof() for C++ after 2011/03, so any use of them gives undefined behaviour which might be to do the right thing. But no one knows what that is or when it is done since none of this is documented in a man page. sys/cdefs.h is now about 8.5 times as large and more than that many times as complicated and ugly as an FreeBSD-1 where it only had __P(()) and a few other portability macros to hide the differences between K&R and C90. It should be 8.5 times smaller (11 lines). It contains a mixture of old and new portability macros and perhaps some standard macros for newer C++ and C. I checked that it doesn't define anything without at least 1 leading underscore except for const, inline, signed and volatile in old compatibility modes. Bruce