Structure editor showing wrong size for Ptr + Integer in 64 bit

I noticed that when I set my OSX project to build for 64 bit, the sizes shown in the structure editor still show the values as if for 32 bit, e.g. Ptr is still 4 byte long.
Is that a known issue? Because I cannot find a bug report about this.
Or am I doing something wrong?

Also, I noticed that 64 bit values in the struct do not get auto-aligned, forcing me to add fillers by hand. I hope this will stay this way so that my code I’m making to work now for 64 bit won’t get broken later again when automatic alignment suddenly happens?

You can use the attribute “StructureAlignment” with the value ??“0” for structure.

Although — isn’t StructureAlignment = 0 the default? Because that’s not working.

Also - damn LR’s serarch doesn’t find “StructureAlignment”, even though it’s right in there, under the LR item “Structure”

Also, when changing the StructureAlignment to 8, the alignment still shows wrong in the editor. I’m confused.

Yeah, there’s still something wrong with that attribute.

First off, StructureAlignment=0 is not the same as not specifying any such attribute.

But StructureAlignment=0 is the same as StructureAlignment=8, which is still wrong for OSX 64, and only StructureAlignment=16 gets it right. Odd.

[quote=232699:@Thomas Tempelmann]Yeah, there’s still something wrong with that attribute.

First off, StructureAlignment=0 is not the same as not specifying any such attribute.[/quote]

This is largely for historical reasons. There weren’t attributes when structures were first added to the language and the structures were all packed (with the idea being that padding could be added explicitly).

The StructureAlignment attribute was added later on, with the acceptable values being 1, 2, 4, 8, 16, 32, 65, and 128. The layout for structures with an explicit alignment differs from the platform’s C ABI would do, but I can’t recall the nuances of the layout code (it might have been issues with under-aligned structures). It’s also problematic because it requires users to have knowledge about the target and how the ABI works in order to pick the correct value.

When 64-bit support was added to iOS earlier this year, the opportunity was taken to clean this situation up a bit. The StructureAlignment attribute can be set to 0 in order to get natural alignment, as dictated by the target platform ABI (using MSVC’s ABI on Windows). The compiler knows about the alignment requirements of all the types and should match how a C compiler lays fields out.

I would love for natural alignment to be the default, but that would alter the semantics of programs that rely on the current behavior of structures being packed.

Are you talking about the compiler’s behavior or the display in the IDE?

[quote=232821:@Joe Ranieri]@Thomas Tempelmann But StructureAlignment=0 is the same as StructureAlignment=8, which is still wrong for OSX 64, and only StructureAlignment=16 gets it right. Odd.
Are you talking about the compiler’s behavior or the display in the IDE?[/quote]
I am talking about the compiler’s behavior. So, why does a value of 16 align the fields on 8-byte boundaries? And why does a value of 0 not align on 8 byte boundaries (all for OSX 64 bit builds)?

Oh, it’s getting weirder. As long as only 4 and 8 byte types are involved, an alignment of anything bigger than 8 acts like an alignment for 8, it seems. So I guess the ABI doesn’t work as I thought it would. My bad.
And while I am pretty sure I didn’t get to work it initially with alignment 0 or 8, it now works, after changing some of the types in the struct, so it appears I had made wrong assumptions on how this alignment works.

Joe, thanks for explaining, but don’t bother any further. I’ve got it working now, and that’s all I needed.

Besides, while testing all this for over an hour now, I ran into 4 bugs in the IDE (Undo not working right, dragging of folders in the left pane moving all items outside the folder, changes to the compat values not being saved and another annoying one where the right panel acts up). This is all so frustrating.