From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14956 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: freeaddrinfo() comments and questions Date: Sat, 23 Nov 2019 12:41:30 -0500 Message-ID: <20191123174130.GI16318@brightrain.aerifal.cx> References: <87v9ra7f42.fsf@mid.deneb.enyo.de> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="77828"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: gilles@poolp.org, musl@lists.openwall.com To: Florian Weimer Original-X-From: musl-return-14972-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 23 18:41:53 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iYZPr-000K6M-EU for gllmg-musl@m.gmane.org; Sat, 23 Nov 2019 18:41:51 +0100 Original-Received: (qmail 8176 invoked by uid 550); 23 Nov 2019 17:41:49 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 8158 invoked from network); 23 Nov 2019 17:41:48 -0000 Content-Disposition: inline In-Reply-To: <87v9ra7f42.fsf@mid.deneb.enyo.de> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14956 Archived-At: On Sat, Nov 23, 2019 at 05:05:17PM +0100, Florian Weimer wrote: > * gilles: > > > In these other implementations, it is possible to write a custom > > struct addrinfo allocator and use freeaddrinfo() on it, just like it > > is possible to use getaddrinfo() and use a custom release function on > > it. This is not a very common use-case, granted, but it is one > > nonetheless, and one that works and has worked in a portable way for a > > long time across a wide variety of systems. > > I think this is clearly undefined. There is no way to know how > storage for ai_addr and ai_canonname is managed. These pointers could > point to separate allocations, made with malloc. They could be > interior pointers to the same top-level allocation at which start the > struct addrinfo object is allocated. Nothing even needs to use > malloc, including the outer struct addrinfo object. Indeed, this is absolutely undefined. Even the way the storage for the addrinfo structures themselves is allocated is unspecified. It need not be by malloc. For example if libc allowed malloc interposition, but only used the interposed functions itself for functions specified to return something allocated as if by malloc, and otherwise always used its internal malloc, then you would end up with a mix of structures allocated by different allocators, and passing one to the other's free would blow up. And of course they could be allocated by direct mmap, or from a static pool, or any of an unlimited number of other possible ways. Rich