[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 May 2014 12:35:55 +0200
From: Paweł Dziepak <pdziepak@...rnos.org>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] add definition of max_align_t to stddef.h
Rich Felker wrote:
>On Sun, May 04, 2014 at 04:36:03AM +0200, Paweł Dziepak wrote:
>> 2014-04-30 23:42 GMT+02:00 Szabolcs Nagy <nsz@...t70.net>:
>> > * Pawel Dziepak <pdziepak@...rnos.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?
>
> #define ll 0
> #include <stddef.h>
Ah, I didn't thought about that. Thanks for clarification.
>> > 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
>
> It's also wrong. The correct alignment for max_align_t on i386 is 4,
> not 8. It's a bug that GCC ever returns 8 for alignof on i386. We
> really need to file a bug against GCC and explain this clearly,
> because I have a feeling they're going to be opposed to fixing it...
>
>> 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
>
> You're completely right; GCC is wrong.
>
>> 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;
>> };
>
> This should not give results different from omitting the "alignas".
> The only reason it does give different results is a bug in GCC, so we
> should not be copying this confusing mess that's a no-op for a correct
> compiler. (Applying alignas(T) to type T is always a no-op.)
I should have checked whether GCC 4.9 has changed before sending that.
As I said earlier, alignof in 4.9 seems to be fixed and on i386 for
fundamental types values <=4 are returned. alignof(max_align_t)
remains 8, though.
However, while 4, undobtedly, is the expected value of
alignof(max_align_t) I don't think that 8 is really wrong (well, from
the C11 point of view). The standard is not very specific about what
max_align_t really should be and if the compiler supports larger
alignment in all contexts there is no reason that alignof(max_align_t)
cannot be larger than alignof() of the type with the strictest
alignment requirements.
Obviously, since max_align_t is the part of ABI it is not like the
implementation can set alignof(max_align_t) to any value or it would
risk compatibility problems with binaries compiled with different
max_align_t. Since both GCC and Clang already define max_align_t so
that its alignment is 8 on i386 I think that Musl should do the same.
Paweł
PS Please, do not remove me from CC.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
