Re: [PATCH 06/25] Add struct scratch_buffer and its internal helper functions

[Paul Eggert <eggert at cs dot ucla dot edu>]

Florian Weimer wrote:
> > > +#define SCRATCH_BUFFER_ALIGNMENT \
> > > +  __attribute__ ((aligned (__alignof__ (union {void *p; double d;}))))
> >
> > This should use __attribute__ ((aligned (alignof (max_align_t)))), at
> > least on C11 platforms.
>
> Hmm.  Isn't intmax_t enough?

I don't know about all the platforms, but in theory C11 says one should use 
max_align_t and that types other than intmax_t might have alignments stricter 
than that needed by intmax_t.

>     array whose element size, in bytes, is 512 or smaller, the scratch
>     buffer only has to grown once to make room for at least one more

grown -> grow

> /* Grows *BUFFER so that it can store at least NELEM elements of SIZE

Grows -> grow

>     bytes.  The buffer contents is NOT preserved.  Both NELEM and SIZE

is NOT -> are NOT

>     can be zero.  It is unspecified wheter this function can reduce the

wheter -> whether

>     array size.  It returns true on success, false on allocation

It returns -> Return

>     failure (in which case the old buffer is freed, but *BUFFER remains
>     a free-able state, and errno is set).  */

a free-able -> in a free-able

> Very recent GCC has
> __builtin_umull_overflow, so maybe we can use that one day.

Yes, that's the plan in Gnulib too.

> Empirically, I'm pretty certain the division does not matter
> performance-wise.

Even on platforms where integer division is a subroutine?  Perhaps glibc isn't 
meant for such platforms, but still....