Hi Rich,

I agree with you, especially about the bloat part.

They (haproxy) actually use this function to determine whether the address
they have is a valid IPv6 address.
They pass in either a valid IPv4 or IPv6 address and then rely on this
function to determine which they have (assuming a return value of 0).

After reading the spec more carefully I realise that -1 should be returned
only when the address family is not AF_INET or AF_INET6.

By changing the return value in the IPv6 code to 0 instead of -1, we could
get the correct behaviour without any extra code.

Here is a patch to try and save you a bit of work:

--- a/musl/src/network/inet_pton.c
+++ b/musl/src/network/inet_pton.c
@@ -46,24 +46,24 @@
                        if (!s[1]) break;
                        continue;
                }
-               if (hexval(s[0])<0) return -1;
+               if (hexval(s[0])<0) return 0;
                while (s[0]=='0' && s[1]=='0') s++;
                for (v=j=0; j<5 && (d=hexval(s[j]))>=0; j++)
                        v=16*v+d;
-               if (v > 65535) return -1;
+               if (v > 65535) return 0;
                ip[i] = v;
                if (!s[j]) {
-                       if (brk<0 && i!=7) return -1;
+                       if (brk<0 && i!=7) return 0;
                        break;
                }
                if (i<7) {
                        if (s[j]==':') continue;
-                       if (s[j]!='.') return -1;
+                       if (s[j]!='.') return 0;
                        need_v4=1;
                        i++;
                        break;
                }
-               return -1;
+               return 0;
        }
        if (brk>=0) {
                memmove(ip+brk+7-i, ip+brk, 2*(i+1-brk));
@@ -73,6 +73,6 @@
                *a++ = ip[j]>>8;
                *a++ = ip[j];
        }
-       if (need_v4 &&inet_pton(AF_INET, (void *)s, a-4) <= 0) return -1;
+       if (need_v4 &&inet_pton(AF_INET, (void *)s, a-4) <= 0) return 0;
        return 1;
 }

Regards
Paul



On Sun, Oct 20, 2013 at 4:22 AM, Rich Felker <dalias@aerifal.cx> wrote:

> On Sat, Oct 19, 2013 at 10:57:00PM +0200, Paul Schutte wrote:
> > Hi,
> >
> > I came across this and believe it is a bug.
> >
> > I have found that when you set str to an IPv4 addr of the from
> > "xxx.xxx.xxx.xxx' while the address family is AF_INET6, then instead of
> > returning a 0 to indicate an invalid IPv6 string, it is converted to
> > gibberish.
>
> From what I can tell, it's not converted to gibberish; instead, it's
> wrongly returning an error (-1) instead of a result indicating an
> invalid input string (0). One could argue that it's a programming
> error not to check this, but inet_pton should not have any reason to
> return -1 if the first argument (af) is valid, so one could also argue
> that such checks would be extraneous bloat.
>
> > inet_pton(AF_INET6, "192.168.1.1', &sa) should return 0 if I understand
> the
> > specification correctly.
>
> Agreed.
>
> Rich
>