I wrote: > Nathan Long <he...@nathanmlong.com> writes: >> At least in the case of `inet`, another reason is for accurate comparison. >> IPv4 and IPv6 both have shorthand textual representations; eg `127.1` = >> `127.1.0.0`. Text storage would consider these unequal.
> I'm not sure how much we want to press that point, because AFAICS > the code we use does not have the same abbreviation rules you are > expecting. Notably, it thinks '127.1' means 127.1.0.0. > (We lifted this logic from BIND 20+ years ago, so while it might > not entirely agree with practice elsewhere, it has a respectable > pedigree and I'm hesitant to mess with it.) I spent a little while researching this. BIND stopped including the relevant code at all sometime in the past 10 years, apparently feeling that POSIX standardization means the libc versions of inet_pton() behave sufficiently alike everywhere. You can still find copies of their code at, eg, https://users.isc.org/~each/doxygen/bind9/inet__pton_8c-source.html and there are also versions in the NetBSD source tree and probably elsewhere. As far as I can find, none of these will interpret '127.1' as 127.0.0.1. Some will reject it (which is what the POSIX spec for the function says to do) and some will interpret it as 127.1.0.0. Where 127.1 => 127.0.0.1 seems to come from is inet_addr (in POSIX) and inet_aton (not in POSIX), which are legacy IPv4-only functions. They say (quoting POSIX here): Values specified using IPv4 dotted decimal notation take one of the following forms: a.b.c.d When four parts are specified, each shall be interpreted as a byte of data and assigned, from left to right, to the four bytes of an Internet address. a.b.c When a three-part address is specified, the last part shall be interpreted as a 16-bit quantity and placed in the rightmost two bytes of the network address. This makes the three-part address format convenient for specifying Class B network addresses as "128.net.host". a.b When a two-part address is supplied, the last part shall be interpreted as a 24-bit quantity and placed in the rightmost three bytes of the network address. This makes the two-part address format convenient for specifying Class A network addresses as "net.host". a When only one part is given, the value shall be stored directly in the network address without any byte rearrangement. All numbers supplied as parts in IPv4 dotted decimal notation may be decimal, octal, or hexadecimal. Frankly, I don't think we want to support this. Classful network addresses have gone the way of the dodo. And the fact that it'd be inconsistent with our traditional interpretation for some non-error cases such as '127.1/16'::inet is really problematic. Moreover, the option to allow octal input is a true disaster, not least because there is plenty of code out there that is willing to print IPv4 addresses with zero-padded *decimal* byte values. So at this point I'm very unexcited about touching the behavior of inet_in. Maybe in another universe it would have acted differently, but we have too many years of history with the current behavior. I do take your point about the inet types helping to standardize comparison behavior, but I think we should probably limit the text to talking about IPv6 abbreviations. Maybe like these types offer input error checking and specialized operators and functions (see <xref linkend="functions-net"/>). + They also simplify comparisons of inconsistently-written addresses, + such as abbreviated and unabbreviated IPv6 addresses. </para> regards, tom lane
