svn commit: r292809 - head/lib/libc/stdio

[Bruce Evans]

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