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

[John Baldwin]

On Tuesday, December 29, 2015 03:51:29 PM Ian Lepore wrote:
> On Tue, 2015-12-29 at 11:37 -0800, 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));
> > 	if (error)
> > 		return (NULL);
> > 	p = (FILE *)mem;
> > 	g = (struct glue *)(p + n);
> > 	g->next = NULL;
> > 	g->niobs = n;
> > 	g->iobs = p;
> > 	...
> > 
> > (This presumes that the requested alignment of 'struct glue' is less
> > than
> > the alignment needed by FILE which should be true.)
> > 
> 
> If there's going to be an assumption that __alignof__(glue) <=
> __alignof__(FILE), it might be nice to have a static_assert() of that
> to prevent a future time bomb similar to the one that exploded on arm
> when it turned out the opposite assumption was wrong.

A static assert seems sensible, yes.

-- 
John Baldwin