Re: [PATCH 3/3] stddef: Define max_align_t

[Jens Gustedt <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]

Am Montag, den 28.04.2014, 15:26 +0200 schrieb Szabolcs Nagy:
> no, long long (or any scalar type) cannot be an "over-aligned" type
> 
> "A type having an extended alignment requirement is an over-aligned type."
> "Every over-aligned type is, or contains, a structure or union type with
> a member to which an extended alignment has been applied."

The later is a footnote and so not normative, merely an explanation.

As a restrictive, normative text it makes not much sense to me anyhow.

> > I am not sure that I remember correctly, but it seems to me that i386
> > allows for 4 byte alignment of all types, only that this results in
> > suboptimal code
> 
> if long long has an alignment requirement of 4 byte then _Alignof should say so

I agree that this would certainly easier to cope with

(the compiler could still place them silently on 8 byte boundaries,
where it suits)

> > > 	typedef char max_align_t __attribute__((aligned(__BIGGEST_ALIGNMENT__)));
> > > 
> > > which gives 16 byte alignment on i386 gcc, i thought it was supported
> > > in all contexts
> > 
> > I think this just not necessary and even counter productive.
> 
> depends on what is the semantic meaning of max_align_t
> 
> currently it means "guaranteed to be supported in all contexts"

I think this isn't explicitly mentioned somewhere, but my expectation
is that the alignment of this type is the one that is guaranteed by
malloc and friends. That should be the only semantic to expect from
it.

Jens

-- 
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/   ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090   ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536   ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183   ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]