From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14954 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.linux.lib.musl.general Subject: Re: freeaddrinfo() comments and questions Date: Sat, 23 Nov 2019 17:50:08 +0100 Message-ID: <87lfs67d1b.fsf@mid.deneb.enyo.de> References: <87v9ra7f42.fsf@mid.deneb.enyo.de> <9a9f93674d04ac477e556a307b91ac54@poolp.org> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="133818"; mail-complaints-to="usenet@blaine.gmane.org" Cc: musl@lists.openwall.com To: gilles@poolp.org Original-X-From: musl-return-14970-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 23 17:50:23 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 1iYYc2-000Yeu-76 for gllmg-musl@m.gmane.org; Sat, 23 Nov 2019 17:50:22 +0100 Original-Received: (qmail 21971 invoked by uid 550); 23 Nov 2019 16:50:19 -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 21953 invoked from network); 23 Nov 2019 16:50:19 -0000 In-Reply-To: <9a9f93674d04ac477e556a307b91ac54@poolp.org> (gilles's message of "Sat, 23 Nov 2019 16:31:35 +0000") Xref: news.gmane.org gmane.linux.lib.musl.general:14954 Archived-At: * 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.