home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 243,020 of 243,242   
   Tim Rentsch to Waldek Hebisch   
   Re: UB or not UB? was: On Undefined Beha   
   14 Jan 26 12:53:22   
   
   From: tr.17687@z991.linuxsc.com   
      
   antispam@fricas.org (Waldek Hebisch) writes:   
      
   > 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.   
      
   Right.  As long as alignment requirements are satisfied, an   
   implementation is free to put as much padding as it wants   
   between struct members.   
      
   > 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?   
      
   There are some consistency requirements with respect to other   
   struct types that have a common starting sequence of members.   
   Basically, as long as the rules stay the same from struct to   
   struct (and alignment rules are respected), then there can be   
   however much padding the implementation chooses to add, at any   
   point between struct members (with some additional restrictions   
   for bitfields).   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca