Re: Brokenness in parsing of pg_hba.conf

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

In response to

Responses

Browse pgsql-hackers by date

  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