Strange input/cast semantics for inet

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