linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).