From: antispam@fricas.org   
      
   David Brown  wrote:   
   > 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.   
   >   
   > 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".   
      
   Why not?  Assuming 4 byte int with 4 byte alignment I see nothing   
   wrong with adding 4 byte padding between b and c.  More precisely,   
   implementation could say that after first int field in a struct   
   there is always 4 byte padding.  AFAICS alignment constraints   
   and initial segment rule are satified, padding is not at start   
   of the struct.  Are there any other restrictions?   
      
   > 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]".   
   >   
   > (None of this means you are allowed to access data with "p[i]" or "p +   
   > i" outside of the range of the object that "p" points to or into.)   
   >   
   >> While I can't think of any good reason for an implementation to insert   
   >> padding between those objects, it would not violate any requirement of   
   >> the standard if one did.   
   >>   
   >   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)