[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180605003724.GZ1392@brightrain.aerifal.cx>
Date: Mon, 4 Jun 2018 20:37:24 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: inet_ntop bug in 1.1.19
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@...rnet.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?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
