From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12897 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: Mon, 4 Jun 2018 20:37:24 -0400 Message-ID: <20180605003724.GZ1392@brightrain.aerifal.cx> References: <20180604213921.1741da0d@vostro> 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 1528158937 25474 195.159.176.226 (5 Jun 2018 00:35:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 5 Jun 2018 00:35:37 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12913-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 05 02:35:33 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 1fPzwg-0006V8-KC for gllmg-musl@m.gmane.org; Tue, 05 Jun 2018 02:35:30 +0200 Original-Received: (qmail 17685 invoked by uid 550); 5 Jun 2018 00:37:37 -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 17652 invoked from network); 5 Jun 2018 00:37:37 -0000 Content-Disposition: inline In-Reply-To: <20180604213921.1741da0d@vostro> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12897 Archived-At: 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? Rich