From: david.brown@hesbynett.no   
      
   On 15/01/2026 16:10, Scott Lurndal wrote:   
   > David Brown  writes:   
   >> On 14/01/2026 23:43, Keith Thompson wrote:   
   >>> David Brown  writes:   
   >>>> On 14/01/2026 04:19, James Russell Kuyper Jr. wrote:   
   >   
   >>> 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.   
   >   
   > Including representing typical networking packet headers as structs.   
   >   
   > Fortunately, most C compilers have some form of __attribute__((packed))   
   > to inform the compiler that the structure layout should not be padded.   
      
   I very rarely find any benefit in using packed structs - typically only   
   if the layout was originally designed without thought for alignment, or   
   where the maximum considered alignment was smaller than on modern   
   systems.  My preference is to add padding fields manually, then have a   
   static_assert on the size of the struct to check for problems.  That   
   does not necessarily mean the code is always portable, but at least if   
   it is not going to work on a given platform, I get a compile-time error   
   rather than a mystical bug!   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)