Re: [PATCH] add definition of max_align_t to stddef.h

[Rich Felker <dalias@libc.org>]

On Thu, May 08, 2014 at 06:41:19PM +0200, Paweł Dziepak wrote:
> > As I see it, we have a choice whether to use the "8" definition on
> > i386 or use the natural definition, which would yield "4" on i386.
> > This is not an ABI issue (it does not affect the ability to use
> > glibc-built object files/binaries/shared libraries with musl, nor the
> > C++ name mangling ABI) but an API issue.
> 
> What about something like this?
> 
> struct foobar {
>     char foo;
>     alignas(max_align_t) char bar;
> };
> 
> The binary representation of this structure depends on the definition
> of max_align_t and binaries compiled with different
> alignof(max_align_t) won't be compatible.

Indeed. This is not an ABI issue with libc.so, but it's an API
difference that translates into an ABI difference between third-party
translation units if they use max_align_t as you've described. Whether
we care, I'm not sure. At least historically there were other cases
like this in musl where type sizes differed in ways that didn't affect
libc ABI but did affect ABI between third-party programs (jmp_buf
comes to mind) but most if not all of these were changed.

I'm not strongly opposed to imposing the 8-byte alignment requirement
on malloc (it would be hard to make malloc work on smaller granularity
anyway, and most archs need 8-byte alignment anyway for long long and
for double) but I generally dislike the inconsistency of defining
max_align_t in a semi-absurd way on i386, as well as the issue of
having to use non-portable definitions and/or arch-specific ones.

BTW in your above example, it's not even clear to me if that use of
alignas is valid. It makes no sense for an object to have an alignment
that does not divide its type (imagine if you added [2] to the end of
bar) and in other places (like the contract of aligned_alloc)
alignments that do not divide the size are explicitly illegal. I'd
like to understand this before making a decision.

Rich