From: James Hanley <jhanley@dgtlrift.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org
Subject: Re: in6_addr struct union with uint64_t
Date: Mon, 29 Jan 2024 13:02:11 -0500 [thread overview]
Message-ID: <CAF++6APqTNuLgB8XkH8bHboAjqqoogY4h=h+ohXh-agaQaVQZA@mail.gmail.com> (raw)
In-Reply-To: <87a5or28dd.fsf@oldenburg.str.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]
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
>
>
next prev parent reply other threads:[~2024-01-29 18:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 14:57 James Hanley
2024-01-26 19:38 ` Florian Weimer
2024-01-29 18:02 ` James Hanley [this message]
2024-01-29 19:08 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAF++6APqTNuLgB8XkH8bHboAjqqoogY4h=h+ohXh-agaQaVQZA@mail.gmail.com' \
--to=jhanley@dgtlrift.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).