I believe I understand your point - is the concern that the alignment issue
would be manifested with an already compiled legacy application utilizing
this newly built library and would require the in6_addr to be 16-byte
aligned or hit a runtime exception if the address passed in isn't aligned -
correct?

Is that why the definition has never gone beyond 4-byte words for the
in6_addr union to stay alignment compatible with in_addr IPv4 address?

On Fri, Jan 26, 2024 at 2:38 PM Florian Weimer <fweimer@redhat.com> wrote:

> * James Hanley:
>
> > #if !__USE_KERNEL_IPV6_DEFS
> > /* IPv6 address */
> > struct in6_addr
> >   {
> >     union
> >       {
> >         uint8_t __u6_addr8[16];
> >         uint16_t __u6_addr16[8];
> >         uint32_t __u6_addr32[4];
> >         uint64_t __u6_addr64[2]; // new
> >         unsigned __int128 __u6_addr128; // new
> >       } __in6_u;
> > #define s6_addr                 __in6_u.__u6_addr8
> > #ifdef __USE_MISC
> > # define s6_addr16              __in6_u.__u6_addr16
> > # define s6_addr32              __in6_u.__u6_addr32
> > # define s6_addr64              __in6_u.__u6_addr64
> > # define s6_addr128             __in6_u.__u6_addr128
> > #endif
> >   };
> > #endif /* !__USE_KERNEL_IPV6_DEFS */
> >
> > First, is this useful, and is there a standard that prohibits defining
> > additional union members?
>
> It changes alignment from 4 bytes to 16 bytes on some architectures,
> which is an ABI-breaking change.  For example, if a member of type
> struct in6_addr is embedded in a struct, it may require additional
> padding in front of it as a result of this change.
>
> Compilers should be able to use wider instructions if beneficial.
>
> Thanks,
> Florian
>
>