From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14957 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:48:36 -0500 Message-ID: <20191123174836.GJ16318@brightrain.aerifal.cx> References: <87v9ra7f42.fsf@mid.deneb.enyo.de> <9a9f93674d04ac477e556a307b91ac54@poolp.org> <87lfs67d1b.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="105754"; 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-14973-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 23 18:48:54 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 1iYZWg-000RPf-Ea for gllmg-musl@m.gmane.org; Sat, 23 Nov 2019 18:48:54 +0100 Original-Received: (qmail 11859 invoked by uid 550); 23 Nov 2019 17:48:52 -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 11841 invoked from network); 23 Nov 2019 17:48:51 -0000 Content-Disposition: inline In-Reply-To: <87lfs67d1b.fsf@mid.deneb.enyo.de> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14957 Archived-At: On Sat, Nov 23, 2019 at 05:50:08PM +0100, Florian Weimer wrote: > * gilles: > > > November 23, 2019 5:05 PM, "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. > > > > Fair enough for this use-case, I think you are right and it works by accident. > > > > What is your opinion on the other comments ? > > The most obvious interpretation is that callers can tweak the ai_next > member before calling freeaddrinfo, and that freeaddrinfo performs the > usual iteration over this single-linked list, freeing each list > element individually. > > In general, relying on this does not seem particularly useful to me. > Applications should probably call freeaddrinfo only on the pointer > provided by getaddrinfo, and refrain from writing to any struct > members. The strictest interpretation is that you can't modify the list at all, and call freeaddrinfo only on the original (entire) list or some tail of it. However I think the spec is ambiguous and it's worth supporting the case where the list has been split by nulling an ai_next pointer. Perhaps removing segments by updating ai_next to point to some later tail of the list is also intended to be ok. Anything beyond that seems pretty dubious to me. To me, the intended use of this functionality seems to be that you might want to remove unwanted entries from the returned list, without having to make your own container structure to store the ones you want to keep. Freeing parts of it is not useful to save memory; rather, the idea of freeing parts is that, if the implementation itself can't reach the list members you remove, it would have no way to free them later when you free the list. Thus it's expected that you notify the implementation you're removing them by calling freeaddrinfo on sublists. Unfortunately all of this is underspecified. Rich