On 08/26/2016 10:54 PM, Joseph Myers wrote:
Such an increase is of course an ABI change, but a reasonably safe one, in that max_align_t doesn't tend to appear in library interfaces (rather, it's something to use when writing allocators and similar code; most matches found on codesearch.debian.net look like copies of the gnulib stddef.h module rather than anything actually using max_align_t at all).
The crucial question is whether GCC will start assuming that pointers returned by malloc (or attribute-malloc functions) have such an alignment. That seems impossible.
I'm pretty sure it does not right now because few mallocs have this property (jemalloc, tcmalloc, and until recently glibc's malloc on 32-bit powerpc and MIPS failed this requirement). They only provide 8-byte alignment even though the fundamental alignment is 16. For the dl-minimal malloc in glibc, the glibc consensus was to ignore max_align_t and go with the regular malloc alignment.
Depending on what your malloc looks like, it can be very tempting *not* to provide 16-byte alignment for pointers returned from malloc (8) or strdup ("abc"), and practical evidence, gained with non-glibc malloc on x86_64 (where the fundamental alignment is 16), suggests that this is currently feasible.
In the end, max_align_t is ignored by allocators, and applications cannot rely on it as a result.
Florian
