From: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
To: Bruce Momjian <maillist@candle.pha.pa.us>
To: Tom Ivar Helbekkmo <tih@nhh.no>
Cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Open 6.4 items
Date: Thu, 08 Oct 1998 07:13:37 +0000
Message-ID: <361C6621.AA1EE6E@alumni.caltech.edu> (raw)
References: <199810080012.UAA15620@candle.pha.pa.us>
> > Looks good to me. I haven't done really heavy testing yet, and I'd
> > also like to update the regression test
> OK. I think Thomas is adding it to the regression tests, particularly
> so people can see how it works. Your readme is now in the manual.
It would be great if you could gin up a real regression test, since I'm
up to my eyeballs in other Postgres projects. But if you can't, or want
some help, let me know. I'd be happy to help with integration of the
test...
> > One problem though, seemingly lately introduced: It's nice
> > to input IP addresses in various formats...
> > One of the common formats is a network byte order hex
> > string, like 0x12345678. Until very recently, I could check what
> > the heck the actual address behind such a representation was, by
> > going "select '0x12345678'::ipaddr;". This no longer works, because
> > the system now helpfully transforms the hex into a long int or
> > something and then tries to treat the result as an ipaddr. Uh-oh.
There is a problem, but this is not the explanation. See below...
> > The intuitively correct thing would be for the hex string to be read
> > and converted as a numeric value only if the type it is being cast
> > to is, indeed, numeric in nature. In the given case, it should be
> > up to ipaddr_in() to make sense of the character string.
What you describe as "no longer works" is actually a core dump on my
machine:
postgres=> select 'x12345678'::ipaddr;
ERROR: could not parse "x12345678"
postgres=> select '0x12345678'::ipaddr;
pqReadData() -- backend closed the channel unexpectedly.
Any single-quote-delimited string is passed to the corresponding _in()
routine without change. So the system is not changing anything before
ipaddr_in() sees it for input. It appears that the _in() code tries to
handle strings starting with "X", but fails to do so (though I'm not
exactly sure what a correct value would look like; I would have guessed
that something like 'x12121212' might be legal, but it fails). It also
appears that the code crashes if there is a leading zero and an
otherwise hex-looking value following, even though it at least sometimes
is checking that each character is valid.
I haven't looked at it further, but the core dump feature should be a
"must-fix" and I would put the "hex input" in the same category since
the code claims to handle it but doesn't. Volunteers?
- Tom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: lockhart@alumni.caltech.edu, maillist@candle.pha.pa.us, tih@nhh.no, hackers@postgreSQL.org
Subject: Re: [HACKERS] Open 6.4 items
In-Reply-To: <361C6621.AA1EE6E@alumni.caltech.edu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox