Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 4 May 2014 01:02:13 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] add definition of max_align_t to stddef.h

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>

> > 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.)

Rich

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.