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
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
