From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=99RV=6B=libc.org=dalias@sourceware.org>
Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13])
	by sourceware.org (Postfix) with ESMTPS id C5DAF3858C50
	for <libc-alpha@sourceware.org>; Sun,  5 Feb 2023 23:44:00 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C5DAF3858C50
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=libc.org
Date: Sun, 5 Feb 2023 18:43:59 -0500
From: Rich Felker <dalias@libc.org>
To: Alejandro Colomar <alx.manpages@gmail.com>
Cc: linux-man@vger.kernel.org, Alejandro Colomar <alx@kernel.org>,
	GCC <gcc@gcc.gnu.org>, glibc <libc-alpha@sourceware.org>,
	Bastien =?utf-8?Q?Roucari=C3=A8s?= <rouca@debian.org>,
	Stefan Puiu <stefan.puiu@gmail.com>, Igor Sysoev <igor@sysoev.ru>,
	Andrew Clayton <a.clayton@nginx.com>,
	Richard Biener <richard.guenther@gmail.com>,
	Zack Weinberg <zack@owlfolio.org>,
	Florian Weimer <fweimer@redhat.com>,
	Joseph Myers <joseph@codesourcery.com>,
	Jakub Jelinek <jakub@redhat.com>, Eric Blake <eblake@redhat.com>
Subject: Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed
 using a union
Message-ID: <20230205234359.GF3298@brightrain.aerifal.cx>
References: <20230205152835.17413-1-alx@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230205152835.17413-1-alx@kernel.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <libc-alpha.sourceware.org>

On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote:
> As discussed before, and Bastien and I seem to agree, ideally we should
> define the following types:
> 
>     struct sockaddr_storage {
>         union {
>             struct {
>                 sa_family_t      ss_family;
>             };
>             struct sockaddr_in   sin;
>             struct sockaddr_in6  sin6;
>             struct sockaddr_un   sun;
>             // ...
>         };
>     };

AFAIK this is not permitted because of namespace. sys/socket.h is not
permitted to expose sockaddr_{in,in6,un}. And if you defined
differently-tagged structures with the same contents, it would not do
any good; accessing the members with the wrong-tagged struct type
would still be UB.

Really, there is no action needed here. Nothing is wrong on libc's
side. The problem is just that the type is *not useful for anything*
and should not be used except in the context of sizeof, which is
purely a documentation issue.

>     struct [[deprecated]] sockaddr {
>         sa_family_t              sa_family;
>     };
> 
>     union [[gnu::transparent_union]] sockaddr_ptr {
>         struct sockaddr_storage  *ss;
>         struct sockaddr          *sa;
>     };
> 
> And then we could define APIs like:
> 
>     int bind(int sockfd, const union sockaddr_ptr *addr, socklen_t len);

You cannot just change APIs because you wish they were different.
Ideally bind, etc. would just take void *, which is what the struct
sockaddr * is being used as. But they don't, so callers have to cast.
It's ugly but it's really not a big deal. Much less of a big deal than
breaking the interface because you think it would look prettier if it
had been done differently.

Rich