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

["Paweł Dziepak" <pdziepak@quarnos.org>]

2014-04-30 23:42 GMT+02:00 Szabolcs Nagy <nsz@port70.net>:
> * Pawel Dziepak <pdziepak@quarnos.org> [2014-04-30 22:23:01 +0200]:
>>
>> +TYPEDEF union { long double ld; long long ll; } max_align_t;
>
> this is wrong
>
> - ld and ll identifiers are not reserved for the implementation
> (you could name them _ld, _ll or __ld, __ll etc)

I will fix that. However, I must admit I don't see why members of the
union (or struct) have to use identifiers reserved for the
implementation. It's not like they can conflict with anything, isn't
it?

> and see previous max_align_t discussion
> http://www.openwall.com/lists/musl/2014/04/28/8
>
> - compiler implementations are non-conforming on some platforms
> (_Alignof returns inconsistent results for the same object type so
> reasoning about alignments is problematic, there are exceptions
> where this is allowed in c++11 but not in c11)
>
> - max_align_t is part of the abi and your solution is incompatible
> with gcc and clang (your definition gives 4 byte _Alignof(max_align_t)
> on i386 instead of 8)

The behavior of _Alignof on x86 is indeed quite surprising. I actually
don't see why 8 is the right value and 4 isn't - System V ABI for x86
doesn't mention any type with alignment 8. Anyway, I agree that it
would be a good thing to mach the definition gcc and clang use, i.e.
something like that:

union max_align_t {
    alignas(long long) long long _ll;
    alignas(long double) long double _ld;
};

> there is probably not much choice and musl will have to copy the
> silly definition used in gcc/clang making max_align_t not very
> useful (it does not reflect malloc alignment supported by the libc
> nor the object alignments supported by the compiler)

Well, alignments supported by the compiler may be different from the
alignments supported by the libc and that depends on how the
implementation supports extended alignments. max_align_t specifies the
greatest fundamental alignment which is guaranteed to be supported in
all contexts (i.e. it's at least as strict as the strictest alignment
required by fundamental types).

Paweł