core.runtime.GC memory alignment

[Manu]

On 29 October 2013 13:47, growler <growlercab at gmail.com> wrote:

> On Tuesday, 29 October 2013 at 00:45:59 UTC, Manu wrote:
>
>> On 29 October 2013 04:33, monarch_dodra <monarchdodra at 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131029/a0ad7edd/attachment-0001.html>