From: Alejandro Colomar <alx.manpages@gmail.com>
To: "Bastien Roucariès" <rouca@debian.org>
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: Fri, 20 Jan 2023 00:31:09 +0100 [thread overview]
Message-ID: <528e35f3-ee79-52e0-be5b-ea5572cf3d07@gmail.com> (raw)
In-Reply-To: <18201055.pzcD54PWfD@portable-bastien>
[-- Attachment #1.1: Type: text/plain, Size: 2493 bytes --]
On 1/19/23 22:38, Bastien Roucariès wrote:
> 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
However... Considering that most APIs use `struct sockaddr *`, this wouldn't
allow the internal libc implementation of functions like getnameinfo(3) to be
free of UB.
Maybe a better thing would be to do the following:
struct sockaddr {
union {
struct {
sa_family_t sa_family;
char sa_data[];
};
struct sockaddr_in sin;
struct sockaddr_in6 sin6;
struct sockaddr_un sun;
};
};
struct sockaddr_storage {
union {
sa_family_t ss_family;
struct sockaddr sa;
};
};
This makes sockaddr and sockaddr_storage have the same size, and also both can
alias any of the children types through the unions, so one can use either of
them for the same purpose.
I'll be sending a patch soon for discussion.
Cheers,
Alex
>
>>
>>>
>>> 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;
>>
--
<http://www.alejandro-colomar.es/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-01-19 23:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-17 10:22 Improve getsockname Bastien Roucariès
2023-01-19 12:42 ` Alejandro Colomar
2023-01-19 19:44 ` Bastien Roucariès
2023-01-19 20:19 ` struct sockaddr_storage, union (was: Improve getsockname) 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
2023-01-19 23:31 ` Alejandro Colomar [this message]
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=528e35f3-ee79-52e0-be5b-ea5572cf3d07@gmail.com \
--to=alx.manpages@gmail.com \
--cc=eblake@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-man@vger.kernel.org \
--cc=rouca@debian.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 NNTP newsgroup(s).