This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 06/25] Add struct scratch_buffer and its internal helper functions
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 23 Mar 2015 19:45:00 +0100
- Subject: Re: [PATCH 06/25] Add struct scratch_buffer and its internal helper functions
- Authentication-results: sourceware.org; auth=none
- References: <cover dot 1425285061 dot git dot fweimer at redhat dot com> <7a6fe503fb764beee3d5b89662d3bbf65242161c dot 1425285061 dot git dot fweimer at redhat dot com> <54F4BB15 dot 7070409 at cs dot ucla dot edu> <550C37F7 dot 10504 at redhat dot com> <550C4AE0 dot 60205 at cs dot ucla dot edu> <55103BEA dot 7070305 at redhat dot com> <5510505B dot 8060209 at cs dot ucla dot edu> <alpine dot DEB dot 2 dot 10 dot 1503231839380 dot 14930 at digraph dot polyomino dot org dot uk>
On 03/23/2015 07:41 PM, Joseph Myers wrote:
>> Since C allows platforms where pointers and/or floating-point values have
>> alignments stricter than intmax_t, I suggest using 'max (__alignof__
>> (intmax_t), __alignof__ (max_align_t))' along with a comment explaining why
>> you don't trust max_align_t here.
>
> max_align_t was added to stddef.h in GCC 4.7, so we can't rely on it in
> glibc without appropriate conditionals.
We compile glibc in -std=gnu99 mode, and max_align_t appears available.
Suggestions?
I was confused about the max_align_t semantics, it's not a problem using
it here if we can get it.
--
Florian Weimer / Red Hat Product Security