From: "Bastien Roucariès" <rouca@debian.org>
To: Alejandro Colomar <alx.manpages@gmail.com>
Cc: "linux-man@vger.kernel.org" <linux-man@vger.kernel.org>,
eblake <eblake@redhat.com>, Zack Weinberg <zack@owlfolio.org>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: struct sockaddr_storage, union (was: Improve getsockname)
Date: Thu, 19 Jan 2023 21:38:54 +0000 [thread overview]
Message-ID: <18201055.pzcD54PWfD@portable-bastien> (raw)
In-Reply-To: <b709c21f-2553-8679-fde9-49d7400ca4ca@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3562 bytes --]
Le jeudi 19 janvier 2023, 21:19:49 UTC Alejandro Colomar a écrit :
>
> On 1/19/23 22:00, Bastien Roucariès wrote:
> [...]
>
> >> <https://inbox.sourceware.org/libc-alpha/0f25d60f-f183-b518-b6c1-6d46aa63ee57@gmail.com/T/>
> >
> > I do not believe it is broken by design. It should be used with care and warning.
> >
> > BTW if we go to the anonymous union way could we add at the end a _null_reserved_field. It will help for unix socket and the infamous sun_path could not end with null...
> > May be it is too late from an ABI point of view, but for me the posix contract from an ABI point of view is that I said in the note sockaddr_storage could grow but not be reduced.
>
> Yes, many types have seen such additions at the end of it over time. In the
> Linux man-pages, I try to document all structures as "having at least these
> members", but may grow over time.
In fact it is not needed and it is the best argument of struct sockaddr_storage
printf("%li %li",sizeof(struct sockaddr_storage),sizeof(struct sockaddr_un));
give me 128 vs 110...
So if correctly documented and aliasing solved it will be the best of the world...
Moreover kernel expect it https://elixir.bootlin.com/linux/latest/source/net/unix/af_unix.c#L293
>
> >
> > struct sockaddr_storage {
> > union {
> > sa_family_t ss_family;
> > struct sockaddr sa;
> > struct sockaddr_in sin;
> > struct sockaddr_in6 sin6;
> > struct sockaddr_un sun;
> > };
> > char __reserved_null;
>
> Such a field would make sense. In fact, I believe the Linux internal
> implementation of _un must have something similar, since it ensures
> null-termination even if the user passes a non-terminated string, IIRC.
>
> > };
> >
> [...]
>
> >> This is compatible:
> >>
> >> - It had at least the `ss_family` field. It's still there, at the same binary
> >> location.
> >> - It has a size at least as large as any other sockaddr_* structure, and a
> >> suitable alignment.
> >> - Old code still works with it just fine.
> >> - New code will be able to avoid UB, and all casts, just by accessing the right
> >> structure element.
> >> - It's trivial to test at configure time if the implementation provides this
> >> new definition of the structure.
> >
> > I agree I could even add a macro for autoconf-archive (I am upstream) and post a patch for gnulib.
>
> Nice; since it's backwards compatible, I'll (probably) suggest a patch for glibc.
>
> >
> >>>>
> >>>>> +.I sockaddr_storage
> >>>>> +structure is large enough to hold any of the other
> >>>>> +.I sockaddr_*
> >>>>> +variants and always well aligned. On return, it should be cast to the correct
> >>>>> +.I sockaddr_*
> >>>>
> >>>> The fact that it is correctly aligned, and a cast will work most of the time,
> >>>> isn't enough for strict aliasing rules. The compiler is free to assume things,
> >>>> just by the fact that it's a different type.
> >>>
> >>> Ok any idea for writing this kind of stuff
> >>
> >> I'm thinking about writing something to several pages; will keep you all updated
> >> on important changes to the pages.
> >
> > Please exchange with me... It is really a pitffall for my student, so I could help here.
>
> Sure. Will do.
>
> Cheers,
>
> Alex
>
> >
> > Bastien
> >>
> >>
> >> Cheers,
> >>
> >> Alex
> >>
> >> --
> >> <http://www.alejandro-colomar.es/>
> >>
> >
>
> --
> <http://www.alejandro-colomar.es/>
>
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-01-19 21:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2889739.XEG2VLDMQ1@portable-bastien>
[not found] ` <5c06b714-80fb-b2c5-0721-72c19f22819f@gmail.com>
[not found] ` <2860541.uBSZ6KuyZf@portable-bastien>
2023-01-19 20:19 ` Alejandro Colomar
2023-01-19 21:00 ` Bastien Roucariès
2023-01-19 21:19 ` Alejandro Colomar
2023-01-19 21:38 ` Bastien Roucariès [this message]
2023-01-19 23:31 ` Alejandro Colomar
2023-01-20 0:12 ` Alejandro Colomar
2023-01-20 21:11 ` Bastien Roucariès
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=18201055.pzcD54PWfD@portable-bastien \
--to=rouca@debian.org \
--cc=alx.manpages@gmail.com \
--cc=eblake@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-man@vger.kernel.org \
--cc=zack@owlfolio.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).