From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14952 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: gilles@poolp.org Newsgroups: gmane.linux.lib.musl.general Subject: freeaddrinfo() comments and questions Date: Sat, 23 Nov 2019 15:46:44 +0000 Message-ID: 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="151138"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14968-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 23 16:48:50 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 1iYXeU-000dCd-8J for gllmg-musl@m.gmane.org; Sat, 23 Nov 2019 16:48:50 +0100 Original-Received: (qmail 29958 invoked by uid 550); 23 Nov 2019 15:48:45 -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 28571 invoked from network); 23 Nov 2019 15:46:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=poolp.org; s=opensmtpd; t=1574524004; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=dga9qp1u/0AaHCYEc3tJOSU22m8ZqZppmDR9S76VgOc=; b=HR4qtfQfQrIcdhpfT4xv6ulwvbDFtyjAJDdj5Dz03VTbieJoakvwbs/BB39IXox0Jkz0cd 8zoBJ61KfRwhTcs06mzygZHnvVth4yZKD4QXVmYUfEoEk7m+m7ajNfwenw7v3EJHoAz6xT 9DDgKoHtS7sabGIg8NfUebhRRcEI0YQ= X-Mailer: RainLoop/1.13.0 Xref: news.gmane.org gmane.linux.lib.musl.general:14952 Archived-At: Hello,=0A=0AI'm not subscribed to the list, please do keep me cc-ed.=0A= =0AThis is just a mail to express my opinion with regard to a somewhat re= cent commit,=0Afeel free to disregard :-)=0A=0A=0AAccording to:=0A=0Ahttp= s://pubs.opengroup.org/onlinepubs/009695399/functions/freeaddrinfo.html= =0A=0AThe freeaddrinfo() function shall free one or more addrinfo structu= res returned by getaddrinfo(), along with any additional storage associat= ed with those structures. If the ai_next field of the structure is not nu= ll, the entire list of structures shall be freed. The freeaddrinfo() func= tion shall support the freeing of arbitrary sublists of an addrinfo list = originally returned by getaddrinfo().=0A=0A=0AIn this commit:=0A=0Ahttps:= //git.musl-libc.org/cgit/musl/commit/src/network/freeaddrinfo.c?id=3Dd139= 5c43c019aec6b855cf3c656bf47c8a719e7f=0A=0ARich Felker states:=0A=0Athe sp= ecification for freeaddrinfo allows it to be used to free=0A"arbitrary su= blists" of the list returned by getaddrinfo. it's not=0Aclearly stated ho= w such sublists come into existence, but the=0Ainterpretation seems to be= that the application can edit the ai_next=0Apointers to cut off a portio= n of the list and then free it.=0A=0A=0AI think that the reason why it's = not clearly stated how such sublists come into existence...=0Ais because = of the mere definition of a sublist:=0A=0A sublist. Noun. (plural subl= ists) A list that makes up part of a larger list.=0A=0A=0AGiven that stru= ct addrinfo is a linked list this doesn't give much room for interpretati= on,=0Aa sublist of the struct addrinfo is just any point after the first = node,=0Abecause that's the only way you can have a list that makes up par= t of a larger list.=0A=0A=0AThis leads to my second point, the musl inter= pretation of the standard leads to an implementation which is not only at= odds with what is found in pretty much every other libc, ranging from BS= D to glibc, but also including Android, Solaris and others, but which als= o prevents the writing of portable code which crafts a struct addrinfo. I= understand that you may not have a goal to do exactly what all the other= s do, but if pretty much every one has the same understanding, it should = at least raise some concern if you're diverging in my opinion.=0A=0AIn th= ese other implementations, it is possible to write a custom struct addrin= fo allocator and use freeaddrinfo() on it, just like it is possible to us= e getaddrinfo() and use a custom release function on it. This is not a ve= ry common use-case, granted, but it is one nonetheless, and one that work= s and has worked in a portable way for a long time across a wide variety = of systems.=0A=0AWith musl, the way struct addrinfo is handled not only p= revents this but also makes the struct addrinfo kind of a weird structure= because it is public, as it should, but relies on an underlying structur= e, struct aibuf, which is not something a user of struct addrinfo would s= ee. Furthermore, the fact that freeaddrinfo() relies on pointer arithmeti= c makes it really clear that struct addrinfo isn't really a linked list b= ut that it's an array of linked elements, and while this may make it much= simpler for musl to handle thread-safety and memory releasing, this is r= eally something that breaks user expectations big time if they assume str= uct addrinfo to be a list and to work as a list.=0A=0AI personally have a= work-around but I really think that this commit was not right and wished= to contribute with my 2 cents if it can provide a different point of vie= w. I don't think any implementation relying on contiguous memory and a si= ngle release can possibly be right as it means the struct addrinfo is not= a list, can't have sublists, can't be self-crafted or self-released.=0A= =0ACheers,=0AGilles