On 29 October 2013 13:47, growler <growler...@gmail.com> wrote: > On Tuesday, 29 October 2013 at 00:45:59 UTC, Manu wrote: > >> On 29 October 2013 04:33, monarch_dodra <monarchdo...@gmail.com> wrote: >> >> On Monday, 28 October 2013 at 02:44:54 UTC, Manu wrote: >>> >>> I had a lot of informal conversations with Walter trying to get my head >>>> around the details here. >>>> To my recollection, the intent was that it should behave like C, and >>>> that >>>> S.alignof must certainly == 128 in that case. It can't work otherwise. >>>> Alignment must be inherited by parent structures. >>>> >>>> >>> But is that really what it means though? From the above conversation, it >>> would instead appear to mean that: >>> struct S >>> { >>> int i; >>> align(128) int j; >>> } >>> in this case, the *padding* needed until we reach j is 128 bytes. >>> >>> It doesn't mean that S itself need to be 128 aligned. >>> >> >> >> Both should be true, if it's not, it's a bug. >> >> > http://dlang.org/attribute.**html#align<http://dlang.org/attribute.html#align> > --- > The alignment for the fields of an aggregate does not affect the alignment > of the aggregate itself - that is affected by the alignment setting outside > of the aggregate. > > align (2) struct S { > align (1): > byte a; // placed at offset 0 > int b; // placed at offset 1 > long c; // placed at offset 5 > } > > auto sz = S.sizeof; // 14 > --- > > My understanding of that is S is not affected by the alignment of its > fields. >
This is a strange test. It looks like your align(1) is intended to mean pack(1), and if that is the case, then the observed sizeof is correct. with pack(1), the size would be 8+4+1 = 13, but then the struct marked align(2) must be padded to a multiple of it's alignment, so 14. What you observe is probably correct, except I don't think the use of align(1) to mean pack(1) is right. That should raise discussion...