Kurt Roeckx wrote:
On Wed, Jan 07, 2004 at 01:58:54PM -0500, Andrew Dunstan wrote:
I read it to mean that abbreviated forms (via inet_addr()) are OK for
AF_INET but not for AF_INET6 (via inet_pton())
But we use AF_UNSPEC/PF_UNSPEC.
Even so, as I read it an IP6 address must follow
Greg Stark wrote:
>
> Kurt Roeckx <[EMAIL PROTECTED]> writes:
>
> > It's a.b.0.c.
> >
> > Note that the "c" can be bigger than 255, so 128.1.512 turns into
> > 128.1.2.0. This can make perfect sense when you still used
> > classes.
>
> Perhaps it'll seem less strange if I restate the rule so t
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> I guess I missed that that section is only about IPv6. So it
> should use inet_addr()'s behaviour.
Well, the question is still whether *our* code is doing anything wrong,
or whether the blame rests entirely with the complainant's C library.
AFAICT the iss
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> It's a.b.0.c.
>
> Note that the "c" can be bigger than 255, so 128.1.512 turns into
> 128.1.2.0. This can make perfect sense when you still used
> classes.
Perhaps it'll seem less strange if I restate the rule so there aren't four
different cases:
A
On Wed, Jan 07, 2004 at 01:58:54PM -0500, Andrew Dunstan wrote:
> Kurt Roeckx wrote:
>
> >[IP6] [Option Start] If the specified address family is AF_INET6 or
> >AF_UNSPEC, standard IPv6 text forms described in inet_ntop() are
> >valid. [Option End]
> I read it to mean that abbreviated
On Wed, Jan 07, 2004 at 01:58:54PM -0500, Andrew Dunstan wrote:
>
> I read it to mean that abbreviated forms (via inet_addr()) are OK for
> AF_INET but not for AF_INET6 (via inet_pton())
>
But we use AF_UNSPEC/PF_UNSPEC.
Kurt
---(end of broadcast)
Kurt Roeckx wrote:
For getaddrinfo() it says:
If the nodename argument is not null, it can be a descriptive name
or can be an address string. If the specified address family is
AF_INET, [IP6] [Option Start] AF_INET6, [Option End] or AF_UNSPEC,
valid descriptive names include host
Bruce Momjian wrote:
Greg Stark wrote:
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
C
On Wed, Jan 07, 2004 at 12:53:19PM -0500, Bruce Momjian wrote:
> Greg Stark wrote:
> > 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 make
Greg Stark wrote:
> 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 n
On Tue, Jan 06, 2004 at 10:52:19PM -0500, Andrew Dunstan wrote:
>
> A few points.
>
> 1. clarification of my IRC comment: A quick examination seems to shaw
> that we use the native getaddrinfo() where it exists, otherwise we use
> our own, which in turn calls inet_ntoa().
> 2. ip6 has a well de
Greg Stark wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> 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) an
"Andrew Dunstan" <[EMAIL PROTECTED]> 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
Alex J. Avriette said:
> On Tue, Jan 06, 2004 at 10:52:19PM -0500, Andrew Dunstan wrote:
>
>> 4. My personal preference would be that if any change is made it would
>> be to insist on an unabbreviated dotted quad for ip4. Alternatively,
>> we
>
> I really think this is the wrong way to approach it
"Alex J. Avriette" <[EMAIL PROTECTED]> writes:
> Given on both Solaris (my database server) and OpenBSD (the machine from
> which that manpage came from) I can connect to 127.1, I think you must
> be mistaken here. What made you think that it isn't supported?
AFAICT, our code simply hands the stri
On Tue, Jan 06, 2004 at 11:38:44PM -0500, Tom Lane wrote:
> AFAICS, Alex is quite far out in left field to believe that this is a
> standard notation. The fact that some BSD platforms have accepted it
How did I know you'd say that, Tom?
By "standard," I mean, "many people use it." Not, "some st
"Alex J. Avriette" <[EMAIL PROTECTED]> writes:
> In how many places are we using inet_aton?
BTW, further digging shows that when the platform has neither
getaddrinfo nor inet_aton, we fall back to src/port/inet_aton.c,
which is a BSD-derived bit of code that behaves exactly as per
your man page qu
"Alex J. Avriette" <[EMAIL PROTECTED]> writes:
> I really think this is the wrong way to approach it. The 127.1
> convention is common, and valid.
AFAICS your own platform's C library doesn't support it, which means
you are on pretty shaky ground to make this claim.
regard
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> 1. clarification of my IRC comment: A quick examination seems to shaw
> that we use the native getaddrinfo() where it exists, otherwise we use
> our own, which in turn calls inet_ntoa().
> 2. ip6 has a well defined standard for abbreviation, and is qui
On Tue, Jan 06, 2004 at 10:52:19PM -0500, Andrew Dunstan wrote:
> 4. My personal preference would be that if any change is made it would
> be to insist on an unabbreviated dotted quad for ip4. Alternatively, we
I really think this is the wrong way to approach it. The 127.1
convention is common,
A few points.
1. clarification of my IRC comment: A quick examination seems to shaw
that we use the native getaddrinfo() where it exists, otherwise we use
our own, which in turn calls inet_ntoa().
2. ip6 has a well defined standard for abbreviation, and is quite
important to have since ip6 addr
So one of the client machines for one of my databases at work resides
on 10.128.0.45. I had to enter something in pg_hba.conf for it today,
as we're bringing this database up. We have a lot of 10/8 subnets, and
I use it at home, so I'm accustomed to just using 10.128.45 for the IP.
Strangely, howev
22 matches
Mail list logo
