On Tue, 16 Feb 2016, Martin Sebor wrote: > Max_align_t need not impact efficiency. In C, the malloc alignment > also need not have an impact on the type since aligned_alloc returns > storage that is (or can be) more strictly aligned.
As per the DR#445 resolution, malloc must return memory "whose alignment is the greatest fundamental alignment". It's obviously necessary for malloc to return memory sufficiently aligned for any object that can be declared within the standard without using over-aligned types. As per DR#075, this applies even to malloc (1). If max_align_t is 64-byte-aligned, malloc (1) must return 64-byte-aligned memory. As a practical matter of ABI compatibility, standard typedefs such as max_align_t should not depend on options for e.g. vector ISA extensions that might affect what alignments are useful (and if a change is needed, it should be a one-off change, only increasing the alignment and not depending on such ISA options). They should also avoid depending on details of implementation limits (e.g. if GCC supports 2^63 byte alignment for ELF in future, that shouldn't need to change max_align_t). > the other storage durations. So for example on a C implementation > like Linux with GLIBC, while conforming, to define max_align_t to > _Alignof(long double) is redunant and less than useful. Programs > can trivially query the alignment of basic types. What they cannot > do (but may need to do) is query the greatest supported alignment in > all contexts/storage durations. If you disregard malloc, that is effectively unbounded (2^28 bytes at least), with current GCC on ELF targets. This is not a useful thing to query, and not useful for malloc to be required to return memory aligned to. -- Joseph S. Myers jos...@codesourcery.com
