"Andrew Dunstan" <andrew@dunslane.net> writes:
> Second, you state that this usage is valid. When you first raised the
> matter, you were so certain that it was sanctified by standard that you
> asked me if I would implement it if you could quote an RFC sanctifying it
> (I said yes) and went off to find one. To your surprise, you couldn't, and
> now want to say that "valid" is defined for every OS in every context by
> the man page for one library call on one OS (or possibly several).
Would the POSIX/IEEE/SuS be authoritative enough?
http://www.opengroup.org/onlinepubs/007904975/functions/getaddrinfo.html
If the specified address family is AF_INET or AF_UNSPEC, address strings using Internet standard dot notation as
specifiedin inet_addr() are valid.
http://www.opengroup.org/onlinepubs/007904975/functions/inet_addr.html
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,
tothe 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
therightmost 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
rightmostthree bytes of the network address. This makes the two-part address format convenient for specifying
ClassA 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.
> Tom has challenged you to prove that this is caused by Pg code and not
> code in your native libraries. Until then, the matter should rest.
Indeed, while I'm not sure what platform the original submitter's using in the
case of glibc it's already a reported bug (by me no less):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=183814
--
greg