From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10086 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: getaddrinfo, ip address sort order? Date: Fri, 3 Jun 2016 12:08:41 -0400 Message-ID: <20160603160840.GO10893@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1464970140 15692 80.91.229.3 (3 Jun 2016 16:09:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Jun 2016 16:09:00 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10099-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 03 18:09:00 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1b8red-0004JT-9e for gllmg-musl@m.gmane.org; Fri, 03 Jun 2016 18:08:59 +0200 Original-Received: (qmail 22392 invoked by uid 550); 3 Jun 2016 16:08:55 -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 22369 invoked from network); 3 Jun 2016 16:08:54 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10086 Archived-At: On Fri, Jun 03, 2016 at 11:21:42AM -0400, John Mudd wrote: > I read that getaddrinfo() returns addresses sorted based on RFC 3484. I'm > using the attached program to test it and I'm not sure if they are sorted. > > I looked at the musl getaddrinfo.c here: > https://github.com/idunham/musl/blob/master/src/network/getaddrinfo.c > > I don't see an obvious sort in the code. Is it there? The relevant code is in src/network/lookup_name.c. The reason it's there is so that it also applies to the legacy host lookup functions. It does not cover 100% of RFC 3484 but should do everything that actually matters/makes sense. Let us know if you run into problems. One known semi-bug is that it uses v4-mapped addresses with AF_INET6 to do the reachability probes for v4 addresses, which may fail on systems with IPv6 completely removed, in which case the code will fail to distinguish that v4 addresses are routable but v6 ones aren't (both may appear non-routable). I plan to go back and fix the code to use AF_INET sockets for probing v4 reachability. Rich