Re: ipv6 bug in inet:ntoa

On Thu, Jul 09, 2015 at 10:10:53AM +0000, Rik Ribbers wrote:
> Hello Raimo,
> 
> You're welcome. As I'm relatively new to Erlang, is there an external
> source where I can monitor this issue?

Nope.  Not yet.  There is work in progress on an external bug tracker.

> 
> Or provide a fix:
> 
> string:to_lower(erlang:integer_to_list(X,16))

I am afraid we can not simply apply such a fix.  I started looking at the
impact of such a change, and directly stumbled upon an OTP application that
uses inet_parse:ntoa/1 to get a string and then uses a regexp to match it
against user supplied data to decide if a connection is allowed.

In other words there are applications depending on an uppercase return
value, so this would be a backwards incompatible change.

So we will have to consider making a new ntoa function...

Best regards.
/ Raimo


> 
> Kind regards,
> Rik
> 
> Op do 9 jul. 2015 om 11:44 schreef Raimo Niskanen <
> [email protected]>:
> 
> > On Fri, Jun 26, 2015 at 08:43:42PM +0000, Rik Ribbers wrote:
> > > Hello,
> > >
> > > I've been playing around with ipv6 in erlang and came across at first
> > > strange behaviour in converting string to ipv6 and back
> > >
> > > ~ --> erl
> > > Erlang/OTP 18 [erts-7.0] [source-4d83b58] [64-bit] [smp:4:4]
> > > [async-threads:10] [hipe] [kernel-poll:false]
> > >
> > > Eshell V7.0  (abort with ^G)
> > > 1>inet:parse_address("2a00:d78::147:94:198:152:68").
> > > {ok,{10752,3448,0,327,148,408,338,104}}
> > > 2> inet:ntoa({10752,3448,0,327,148,408,338,104}).
> > > "2A00:D78:0:147:94:198:152:68"
> > >
> > > If you look closely you will see that there is an extra 0 introduced.
> > This
> > > is actually correct. In IETF RFC5952 section 4.2.2 states that a single 0
> > > must not be shortened. This however introduces however the question is
> > the
> > > inet:parse_address is actually correct, however it is being friendly to
> > its
> > > caller...
> >
> > There is no ambiguity here so why not.
> >
> > >
> > > The real issue is however that the addresses are displayed in uppercase
> > > which is simply wrong. As RFC5952 clearly states in section 4.3. There is
> > > even Errata on this issue that states it must be in lower case.
> > >
> > > The RFC can be found here https://tools.ietf.org/html/rfc5952
> >
> > Oh dear.  We'll probably have to fix that.
> >
> > To my defence I will say that the code is from November 2009 which predates
> > that RFC and that it tries to follow RFC 4291 or maybe RFC 3513.  It also
> > uses
> > erlang:integer_to_list/2 that produces uppercase, just for the same reasons
> > that the rejected Errata voices...
> >
> > Thank you for pointing this out.
> >
> >
> > >
> > > Kind regards,
> > > Rik Ribbers
> >
> > > _______________________________________________
> > > erlang-bugs mailing list
> > > [email protected]
> > > http://erlang.org/mailman/listinfo/erlang-bugs
> >
> >
> > --
> >
> > / Raimo Niskanen, Erlang/OTP, Ericsson AB
> >

> _______________________________________________
> erlang-bugs mailing list
> [email protected]
> http://erlang.org/mailman/listinfo/erlang-bugs


-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-bugs mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-bugs