On 09/05/2016 07:06 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).
I've thought some more about this. I'll try to rephrase my reservations in a less diplomatic way, hopefully making my thoughts clearer.
I think this change is only safe because nothing relies on it. max_align_t is a committee invention with no actual users. As such, you can change it in any way you see fit and it won't make a difference in any way.
Why aren't there any users? The standard isn't very clear what the value of _Alignof (max_align_t) actually means. Does the phrase “all contexts” include pointers returned malloc? Even if the requested size is smaller than the fundamental alignment? Did those who wrote the standard expect there to be *any* relationship between malloc and max_align_t?
The existing situation is that most mallocs to do not provide _Alignof (max_align_t) alignment unconditionally. But they can provide arbitrarily large alignment with aligned_alloc/memalign-style interfaces.
For object alignment declarations, I think GCC can satisfy most requests, perhaps subject to binutils/dynamic linker limitations for global variables on some targets.
The question then is, how can we make max_align_t more useful? If it is supposed to reflect a malloc property, it cannot be a compile-time constant because we don't know at compile time which malloc is going to be used (malloc has to remain interposable). If there is no relationship to malloc, GCC essentially supports unbounded alignment on many targets. How is it possible to have a meaningful definition of max_align_t under such circumstances?
Florian
