This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]