From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Brokenness in parsing of pg_hba.conf |
Date: | 2004-01-07 16:32:36 |
Message-ID: | 87n08zwwgr.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Andrew Dunstan" <andrew(at)dunslane(dot)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 specified in 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, 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.
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2004-01-07 17:27:55 | Re: [COMMITTERS] pgsql-server/ oc/src/sgml/catalogs.sgml rc/bac ... |
Previous Message | Bruno Wolff III | 2004-01-07 15:46:55 | Re: Paypal WAS: PostgreSQL speakers needed for OSCON |