Re: Brokenness in parsing of pg_hba.conf

"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