From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12951 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: inet_ntop bug in 1.1.19 Date: Tue, 26 Jun 2018 16:56:38 -0400 Message-ID: <20180626205638.GC1392@brightrain.aerifal.cx> References: <20180604213921.1741da0d@vostro> <20180605003724.GZ1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1530046487 17032 195.159.176.226 (26 Jun 2018 20:54:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Jun 2018 20:54:47 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Philip Homburg To: musl@lists.openwall.com Original-X-From: musl-return-12967-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 26 22:54:42 2018 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.84_2) (envelope-from ) id 1fXuz4-0004Ly-H8 for gllmg-musl@m.gmane.org; Tue, 26 Jun 2018 22:54:42 +0200 Original-Received: (qmail 7626 invoked by uid 550); 26 Jun 2018 20:56:51 -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 7600 invoked from network); 26 Jun 2018 20:56:50 -0000 Content-Disposition: inline In-Reply-To: <20180605003724.GZ1392@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12951 Archived-At: I think Philip somehow got un-Cc'd and missed further discussion: On Mon, Jun 04, 2018 at 08:37:24PM -0400, Rich Felker wrote: > On Mon, Jun 04, 2018 at 09:39:21PM +0300, Timo Teras wrote: > > On Mon, 04 Jun 2018 14:23:55 +0000 > > "Laurent Bercot" wrote: > > > > > >inet_ntop doesn't conform to RFC 5952 (A Recommendation for IPv6 > > > >Address > > > >Text Representation). > > > > > > > >I attached a test program to demonstrate the issue and a patch: > > > >$ cc inet_ntop_test.c musl-1.1.19/src/network/inet_ntop.c > > > >$ ./a.out > > > >Section 4.2.2 test failed: got 2001:db8::1:1:1:1:1, expected > > > >2001:db8:0:1:1:1:1:1 > > > > > > https://tools.ietf.org/html/rfc5952#section-4.2.1 says: > > > "The use of the symbol "::" MUST be used to its maximum capability." > > > > > > 2001:db8::1:1:1:1:1 is the correct canonical text representation. > > > > The following section 4.2.2 says: > > > > 4.2.2. Handling One 16-Bit 0 Field > > > > The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. > > For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but > > 2001:db8::1:1:1:1:1 is not correct. > > > > Looks like the test case is taken directly from this. > > Lovely -- 4.2.1 and 4.2.2 are outright conflicting. I suppose you're > expected to interpret 4.2.1 as "maximum capability subject to the > nonsensical additional constraint below". > > In any case, 4.2.2 probably makes things prettier to read even if it > does take an extra character. > > I checked and only RFC 2373 is actually normative for inet_pton (per > POSIX), but it doesn't contradict anything in RFC 5952 or provide any > preferred conventions for reverse mapping, so I think it's safe to > adopt the rule in 4.2.2 above. > > Sound ok? Arthur Jones subsequently submitted a slightly simpler patch which I'm applying. Let me know if anything still seems wrong. It now passes the test case. Rich