inet_pton and oddly-formatted addresses

[Ed Maste]

It turns out an application at work is passing an IP address to inet_pton
that is formatted slightly strangely; it ends up being something of the form
1.002.3.4.  In 4.x inet_pton reports this as valid and returns 1.2.3.4.  (I
also checked that it's just ignoring the leading zeros, not parsing the
octet as octal.)  On my 5.x and 6.x machines, inet_pton rejects this string
as invalid.

I discussed this briefly with bz@, who pointed out two relevant RFCs.
RFC 3493 has this to say:

   The inet_pton() function shall convert an address in its standard
   text presentation form into its numeric binary form.

...

   It shall return 0 if the input is not a valid IPv4 dotted-decimal
   string...

The claim can easily be made that 1.002.3.4 is not "standard text
presentation form."  On the other hand, rfc 820 implies that 1.002.3.4 is a
valid dotted decimal form:

   One commonly used notation for internet host addresses divides the
   32-bit address into four 8-bit fields and specifies the value of each
   field as a decimal number with the fields separated by periods.  This
   is called the "dotted decimal" notation.  For example, the internet
   address of ISIF in dotted decimal is 010.002.000.052, or 10.2.0.52.

I think an address like 1.002.3.4 is bizarre, but is our inet_pton incorrect
in rejecting it?

-ed