Why dynamic arrays in a struct crash when they are effectively at 8 byte align, but precceeded with align(1)?

[realhet]

On Wednesday, 14 October 2026 at 12:49:39 UTC, kinke wrote:
> On Wednesday, 14 October 2026 at 12:04:12 UTC, realhet wrote:
>> The struct's footprint is the same, yet it requires default 
>> align: or align(n) at least 8.
>> Are there any official requirements for these fap pointers?
>> (Win32 64bit LDC)
>
> You're hitting 
> https://github.com/ldc-developers/ldc/issues/4236 here, which 
> might get fixed soon (TurkeyMan is currently working on it).
>
Thank You!

I played with it more:
```d
struct ThingId{ uint raw; }

struct S {
     align(1):
     ThingId thingId;
     bool opened;
     S[] subNodes;
}

auto foo_s(S* d) { return d.subNodes.length; }
```

But the asm looks perfect:
```asm
         mov     qword ptr [rbp - 8], rdi
         mov     rax, qword ptr [rbp - 8]
         mov     rax, qword ptr [rax + 5]  //ThingId=4 byte + 
opened=1 byte -> 5
```
In the llvm IR there are align(8) everywhere.

So I guess, to generate am access violation, it must be a more 
complex test code. A treeview visualization triggers it 100%.

 From now on I will use default align for 64bit pointers and 
dynamic arrays.

Although I know that the x64 has no problem with unaligned RAX 
memory access. And I think the GC can handle unaligned pointers 
too, but better be safe.
Those small 8, 16, 32bit fields, I can still align freely, but 
not the big pointers with the lots of zeroes.