Date: Sat, 20 Jan 2007 14:28:07 -0500 From: Ed Maste <emaste@phaedrus.sandvine.ca> To: freebsd-net@freebsd.org Subject: inet_pton and oddly-formatted addresses Message-ID: <20070120192807.GA1326@sandvine.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070120192807.GA1326>