From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id 9DF343858D1E for ; Mon, 6 Feb 2023 17:48:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9DF343858D1E 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: Mon, 6 Feb 2023 12:48:49 -0500 From: Rich Felker To: Alejandro Colomar Cc: Xi Ruoyao , linux-man@vger.kernel.org, Alejandro Colomar , GCC , glibc , Bastien =?utf-8?Q?Roucari=C3=A8s?= , Stefan Puiu , Igor Sysoev , Andrew Clayton , Richard Biener , Zack Weinberg , Florian Weimer , Joseph Myers , Jakub Jelinek , Eric Blake , Michael Kerrisk Subject: Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union Message-ID: <20230206174849.GJ3298@brightrain.aerifal.cx> References: <20230205152835.17413-1-alx@kernel.org> <0a9306fa37edeb4a989b2929de67fee8606a3d8a.camel@xry111.site> <20230206133850.GI3298@brightrain.aerifal.cx> <9998a4eb-528b-b006-ebeb-d94816e62d82@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9998a4eb-528b-b006-ebeb-d94816e62d82@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,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: On Mon, Feb 06, 2023 at 03:11:10PM +0100, Alejandro Colomar wrote: > Hi Rich, > > On 2/6/23 14:38, Rich Felker wrote: > >There is absolutely not any need to declare the union for application > >code calling the socket APIs. You declare whatever type you will be > >using. For binding or connecting a unix socket, sockaddr_un. For IPv6, > >sockaddr_in6. Etc. Then you cast the pointer to struct sockaddr * and > >pass it to the function. > > Except that you may be using generic code that may use either of > AF_UNIX, AF_INET, and AF_INET6. A web server may very well use all > the three. If you have generic code, the generic code is not what's creating the object. It got the object from the calling code or from some callback that allocated it, in which case it doesn't have to care about any of this. > >But normally you don't use declared-type objects for this anyway. You > >use the struct sockaddr * obtained from getaddrinfo as an abstract > >pointer and never dereference it at all. > > That's right. Most of the time, we should be using getaddrinfo(3), > which already provides the storage. I don't know for sure if there > are any cases that can't be rewritten to work that way. > > However, there are some APIs that require you to allocate an object. > For example recvfrom(2). How would you recommend using recvfrom(2), > or is it some API to avoid? Example of usage: > . If using allocated storage, there's nothing special you have to do. But if you want to avoid malloc and use a declared object, you have a few options: If it's your socket and you know what address family it's associated with, you just pass an object of that type. recvfrom will always produce output of the same AF. If you're in a situation like having been invoked from inetd, you can use getsockname into a sockaddr_storage object or union or whatever, then read out the family field (with memcpy if needed). Then you know the AF to use. Or, you can just recvfrom into a sockaddr_storage object, determine the family at that time, then memcpy the the appropriate object type. Alternatively, for the common case where you want a printable name for the address, you just pass it to getnameinfo as-is and let getnameinfo deal with how to read it. Rich