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

[Warner Losh]

Be my guest to implement these things. I don't think it matters much, and
adds a lot of
complexity to avoid a single roundup call. And if we have more-strict
alignment for
glue than ALIGNBYTES, we're already doomed. We don't do that today.

Warner

On Tue, Dec 29, 2015 at 3:51 PM, Ian Lepore <ian at freebsd.org> 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.
>
> -- Ian
>
>