From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14955
Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail
From: gilles@poolp.org
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: freeaddrinfo() comments and questions
Date: Sat, 23 Nov 2019 16:31:35 +0000
Message-ID: <9a9f93674d04ac477e556a307b91ac54@poolp.org>
References: <87v9ra7f42.fsf@mid.deneb.enyo.de>
 <ab0ca8ab851c306afb69163ed15b04b5@poolp.org>
Reply-To: musl@lists.openwall.com
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226";
	logging-data="53959"; mail-complaints-to="usenet@blaine.gmane.org"
Cc: musl@lists.openwall.com
To: "Florian Weimer" <fw@deneb.enyo.de>
Original-X-From: musl-return-14971-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 23 18:36:03 2019
Return-path: <musl-return-14971-gllmg-musl=m.gmane.org@lists.openwall.com>
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 <musl-return-14971-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1iYZKC-000Dqs-K5
	for gllmg-musl@m.gmane.org; Sat, 23 Nov 2019 18:36:00 +0100
Original-Received: (qmail 5456 invoked by uid 550); 23 Nov 2019 17:35:58 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Original-Received: (qmail 15757 invoked from network); 23 Nov 2019 16:31:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=poolp.org; s=opensmtpd;
	t=1574526696;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=uiJ71jbeSwSS+0pBz64ORogeoJ7AMJD0VoZqxVFTcEs=;
	b=S6OugY9MTQCrIn/LuX76r5CxamKbo+prH+Sf+tZ/lxjY1vFO5pXwaBk7IdKSgpyWoRKELR
	UxvEjW0o0G2DLA0iEUMgMOLOL1idyxg65FYTxLEHtKrHsyBS/lGzJZey8NffYvvTRrC7tp
	1j6Yqq4gumAAGeFAmx6o6tecrd9LAbg=
X-Mailer: RainLoop/1.13.0
In-Reply-To: <87v9ra7f42.fsf@mid.deneb.enyo.de>
Xref: news.gmane.org gmane.linux.lib.musl.general:14955
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/14955>

November 23, 2019 5:05 PM, "Florian Weimer" <fw@deneb.enyo.de> wrote:=0A=
=0A> * gilles:=0A> =0A>> In these other implementations, it is possible t=
o write a custom=0A>> struct addrinfo allocator and use freeaddrinfo() on=
 it, just like it=0A>> is possible to use getaddrinfo() and use a custom =
release function on=0A>> it. This is not a very common use-case, granted,=
 but it is one=0A>> nonetheless, and one that works and has worked in a p=
ortable way for a=0A>> long time across a wide variety of systems.=0A> =
=0A> I think this is clearly undefined. There is no way to know how=0A> s=
torage for ai_addr and ai_canonname is managed. These pointers could=0A> =
point to separate allocations, made with malloc. They could be=0A> interi=
or pointers to the same top-level allocation at which start the=0A> struc=
t addrinfo object is allocated. Nothing even needs to use=0A> malloc, inc=
luding the outer struct addrinfo object.=0A=0AFair enough for this use-ca=
se, I think you are right and it works by accident.=0A=0AWhat is your opi=
nion on the other comments=20?