Thread: Strange input/cast semantics for inet
This looks very strange to me:
staging=> select '1.10'::cidr;
cidr
-------------
1.10.0.0/16
(1 row)
The normal way to read "1.10" would be as synonymous with "1.0.0.10". This is
even mandated by the POSIX spec for getaddrinfo and company. q
--
greg
Greg Stark <gsstark@mit.edu> writes:
> The normal way to read "1.10" would be as synonymous with "1.0.0.10".
That might be the case for IPv6, but it's never been a standard
convention for IPv4; and even for IPv6 it doesn't make any sense
for a network (as opposed to host) number.
regards, tom lane
On Thu, Jul 21, 2005 at 06:38:01PM -0400, Tom Lane wrote: > Greg Stark <gsstark@mit.edu> writes: > > The normal way to read "1.10" would be as synonymous with "1.0.0.10". > > That might be the case for IPv6, but it's never been a standard > convention for IPv4; and even for IPv6 it doesn't make any sense > for a network (as opposed to host) number. I don't know if it's ever been blessed by a formal standard, but that way of interpreting an IPv4 address is widely implemented in inet_aton() and friends. The 4.2BSD inet(3) manual page documents that interpretation, and on most (all?) systems I've ever used, "ping 127.1" is a shortcut for pinging the loopback address. -- Michael Fuhr http://www.fuhr.org/~mfuhr/
Michael Fuhr <mike@fuhr.org> writes: > On Thu, Jul 21, 2005 at 06:38:01PM -0400, Tom Lane wrote: > > Greg Stark <gsstark@mit.edu> writes: > > > The normal way to read "1.10" would be as synonymous with "1.0.0.10". > > > > That might be the case for IPv6, but it's never been a standard > > convention for IPv4; and even for IPv6 it doesn't make any sense > > for a network (as opposed to host) number. It has always been the convention for IPv4 for as long as the dotted notation existed. In fact it took a while before the full dotted quad notation really became dominant. For a long time it wasn't clear how large a final segment would become the most popular with many people using 16-bit network masks. > I don't know if it's ever been blessed by a formal standard It's blessed by POSIX: http://www.opengroup.org/onlinepubs/009695399/functions/inet_addr.html I'm really skeptical Vixie would have written things this way. Perhaps somebody at some point later misunderstood the convention and "fixed" the behaviour? -- greg
On Thu, Jul 21, 2005 at 10:14:42PM -0400, Greg Stark wrote: > Michael Fuhr <mike@fuhr.org> writes: > > > I don't know if it's ever been blessed by a formal standard > > It's blessed by POSIX: > > http://www.opengroup.org/onlinepubs/009695399/functions/inet_addr.html Yep, that's lifted almost verbatim out of the 4.2BSD inet(3) manual page. > I'm really skeptical Vixie would have written things this way. Perhaps > somebody at some point later misunderstood the convention and "fixed" the > behaviour? I just ran some tests with the inet_net_pton() function found in the BIND 4.9.11 source code and it behaves the same way as the code in PostgreSQL, viz., 10.1 becomes 10.1.0.0. The code I used had the following rcsid: $Id: inet_net_pton.c,v 8.3 1996/11/11 06:36:52 vixie Exp $ Maybe Vixie didn't like the convention or think it was worth implementing for his needs. Aside from the rare use of "ping 127.1", I do find it more useful to interpret 10.1 as 10.1.0.0 since I'm more likely to use 10.1 as an abbreviation for the "ten dot one network" than as shorthand for 10.0.0.1. I expect I'm not alone in that. -- Michael Fuhr http://www.fuhr.org/~mfuhr/
Greg Stark wrote: > > This looks very strange to me: > > staging=> select '1.10'::cidr; > cidr > ------------- > 1.10.0.0/16 > (1 row) > > > The normal way to read "1.10" would be as synonymous with "1.0.0.10". This is > even mandated by the POSIX spec for getaddrinfo and company. q Interesting. Inet doesn't allow it, but I assume CIDR does because it is a network and the trailing values are just assumed to be zero. It looks OK to me as a CIDR. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073