Re: `inet` docs suggestion and possible bug report

Sounds good. Thanks for researching this!

On Tue, Apr 29, 2025, 4:37 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I wrote:
> > Nathan Long <hello(at)nathanmlong(dot)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
>