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: Thu, 19 Jan 2023 22:19:49 +0100	[thread overview]
Message-ID: <b709c21f-2553-8679-fde9-49d7400ca4ca@gmail.com> (raw)
In-Reply-To: <3299211.1eNo6cvScQ@portable-bastien>


[-- Attachment #1.1: Type: text/plain, Size: 2935 bytes --]



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.

> 
>   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: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-01-19 21:26 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 [this message]
2023-01-19 21:38           ` Bastien Roucariès
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=b709c21f-2553-8679-fde9-49d7400ca4ca@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).