From: david.brown@hesbynett.no
On 14/01/2026 23:43, Keith Thompson wrote:
> David Brown writes:
>> On 14/01/2026 04:19, James Russell Kuyper Jr. wrote:
>>> On 2026-01-12 13:08, Michael S wrote:
>>>> On Mon, 12 Jan 2026 15:58:15 +0000
>>>> bart wrote:
>>> ...
>>>>> struct bar1 {
>>>>> union {
>>>>> struct {
>>>>> int table[4];
>>>>> int other_table[4];
>>>>> };
>>>>> int xtable[8];
>>>>> };
>>>>> };
>>> ...
>>>>> I'm not even sure about there being no padding between .table and
>>>>> .other_table.
>>>>
>>>> Considering that they both 'int' I don't think that it could happen,
>>>> even in standard C.
>>> "Each non-bit-field member of a structure or union object is aligned
>>> in an implementation-defined manner appropriate to its type."
>>> (6.7.3.2p16)
>>> "... There can be unnamed padding within a structure object, but not
>>> at its beginning." (6.7.3.2p17)
>>
>> Does this allow different alignment rules for a type when it is
>> stand-alone, in an array, or in a struct? I don't think so - I have
>> always interpreted this to mean that the alignment is tied to the
>> type, not where the type is used.
>
> Note that the alignof operator applies to a type, not to an expression
> or object.
>
>> Thus if "int" has 4-byte size and 4-byte alignment, and you have :
>>
>> struct X {
>> char a;
>> int b;
>> int c;
>> int ds[4];
>> }
>>
>> then there will be 3 bytes of padding between "a" and "b", but cannot
>> be any between "b" and "c" or between "c" and "ds".
>
> There can be arbitrary padding between struct members, or after the last
> member. Almost(?) all implementations add padding only to satisfy
> alignment requirements, but the standard doesn't state any restrictions.
> There can be no padding before the first member, and offsets of members
> must be increasing.
>
On closer reading, I agree with you here. I find it a little surprising
that this is not implementation-defined. If an implementation can
arbitrarily add extra padding within a struct, it severely limits the
use of structs in contexts outside the current translation unit.
> If alignof (int) is 4, a compiler must place an int object at an address
> that's a multiple of 4. It's free to place it at a multiple of 8, or
> 16, if it chooses.
>
>> Even if you have a weird system that has, say, 3-byte "int" with
>> 4-byte alignment, where you would have a byte of padding between "b"
>> and "c", you would have the same padding there as between "ds[0]" and
>> "ds[1]".
>
> sizeof (int) == 3 and alignof (int) == 4 is not possible. Each type's
> size is a multiple of its alignment. There is no padding between array
> elements.
>
I have not, as yet, found a justification for those statements in the
standards. But I'll keep looking!
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
