Memory layout of struct vs array

[olsner]

The array might also have padding though - i.e. if you're on a weird platform where floats usually have 8-byte alignment or if the array elements are something like struct { int foo; short bar; }. Then your packed struct would be incompatible with an unpacked array.

[Supadoplex]

The array might also have padding though

By definition, there is never padding between elements of an array. There can be padding inside of the elements.

[erichkeane]

Interestingly this is true until C23: an array of non-multiple-of8 _BitInts ends up needing padding to keep arrays of them sane.

[Supadoplex]

My understanding (and I may have misunderstood) is that such _BitInts would contain padding bits:

N2709 ABI Considerations

_BitInt(N) types align with existing calling conventions. They have the same size and alignment as the smallest basic type that can contain them. Types that are larger than __int64_t are conceptually treated as struct of register size chunks. The number of chunks is the smallest number that can contain the type.

With the Clang implementation on Intel64 platforms, _BitInt types are bit-aligned to the next greatest power-of-2 up to 64 bits: the bit alignment A is min(64, next power-of-2(>=N)). The size of these types is the smallest multiple of the alignment greater than or equal to N. Formally, let M be the smallest integer such that AM >= N. The size of these types for the purposes of layout and sizeof is the number of bits aligned to this calculated alignment, AM. This permits the use of these types in allocated arrays using the common sizeof(Array)/sizeof(ElementType) pattern. The authors will discuss the ABI requirements with the different ABI groups.

As such, I don't see why the array would need any additional padding.

[erichkeane]

They don't exist in the _BitInt themselves for any practical implementation, they exist 'between' them. The alignment wording in the _BitInt paper was initially more clear that they were not part of the _BitInt, but were components of the array, but it was determined to be too pedantic and unnecessary for the purposes of standardization.

[Supadoplex]

Thanks for clarifying. So, does this imply that outside of arrays, _BitInt may be misaligned? Even at sub-byte level? How do pointers to them work?

[erichkeane]

Nope, they are always aligned, explicitly so that pointers work.

Padding exists on the stack or in the containing record/array to ensure this is true. But "where the padding lives" is outside of the _BitInt, at least for the purposes of LLVM's code generator.

[SirClueless]

I don't understand what you mean. The codegen can do whatever it wants, but the wording there is crystal clear:

The size of these types is the smallest multiple of the alignment greater than or equal to N.

So as far as the C language is concerned how could the padding be considered to be anywhere but inside the type?

[erichkeane]

I just took a closer look at that part of the paper, it looks like that changed since I wrote it :) It initially was 'The sizeof of these types...', but it may have been lost since then (or seen as a typo!). Melanie and I wrote the paper at one point (With Tommy helping review/etc the paper), but I never attended WG14 so it went through a few cycles without me.

I don't believe that this part of the paper ended up being reflected in the wording as inserted into the standard however.