[lwip-devel] [bug #33485] SOCK_ADDR_TYPE_MATCH and SOCK_ADDR_TYPE_MATCH_OR_UNSPEC use error

[Kieran Mansley]

Follow-up Comment #5, bug #33485 (project lwip):

While a compiler could do that, I think it is unlikely, as it would normally
align a field to a boundary of the size of that type.  Without the "char
pad[]" fields alignment1 is 16 bit aligned, and alignment2 is 32 bit aligned,
i.e they are already on their natural alignment so why insert padding?

Perhaps the compiler would rather store alignment1 as a 32 bit int as that is
more efficient, but if we take that view then why stop at 2 bytes padding
between alignment1 and alignment2?  A compiler could in theory put them both
on 64 bit boundaries (e.g. on a 64 system) if it thought that was better.

Trying to second-guess the compiler and insert padding into structures is
never going to work well across all compilers, apart from in some very limited
cases.  If we really need to avoid padding between fields in a structure then
we must mark it as packed or specify the alignment of fields using
compiler-specific directives.

I'm always pleased to see debug code to check assumptions, so the assertion
idea is fine by me, but I agree with Simon that when the struct sockaddr_in[6]
was allocated by the caller it must have had the correct alignment then, so
although it's come to us via a struct sockaddr the aligment shouldn't have
changed and the compiler's warning (while technically correct) can be thought
of as wrong in this case.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?33485>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/