Re: inet_ntop bug in 1.1.19

[Rich Felker <dalias@libc.org>]

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" <ska-dietlibc@skarnet.org> 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