Tom Lane writes:
> > if (sizeof(unsigned long) > sizeof(Oid) && cvt > UINT_MAX)
>
> Hm. Each part of that will generate "expression is always false"
> warnings from certain overprotective compilers.
Any compiler that does this will certainly issue a boatload of these all
over the tree.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> if (sizeof(unsigned long) > sizeof(Oid) && cvt > UINT_MAX)
Hm. Each part of that will generate "expression is always false"
warnings from certain overprotective compilers. A more serious problem
is that using UINT_MAX assumes that Oid is un
Tom Lane writes:
> Ryan Kirkpatrick <[EMAIL PROTECTED]> writes:
> > INSERT INTO OID_TBL(f1) VALUES ('-1040');
> > ERROR: oidin: error reading "-1040": value too large
>
> That's coming from a possibly-misguided error check that I put into
> oidin():
>
> unsigned long cvt;
> char
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Reading the code, I don't understand it. Why would strtoul return an
> int in the first place ? The name seems to imply an unsigned long
> return type.
What's your point?
unsigned long cvt;
cvt = strtoul(s, &endptr, 10);
The
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> IIRC oid uses int4in/int4out and those should definitely be able to parse
> -1040 into a 4 byte signed long without platform dependency, no ?
It has done that in past releases. I changed it to use unsigned display
for 7.1. Because of the pas
> > IIRC oid uses int4in/int4out and those should definitely be able to parse
> > -1040 into a 4 byte signed long without platform dependency, no ?
>
> Tom Lane changed this recently to have OID use its own i/o routines.
Reading the code, I don't understand it. Why would strtoul return an int i
> IIRC oid uses int4in/int4out and those should definitely be able to parse
> -1040 into a 4 byte signed long without platform dependency, no ?
Tom Lane changed this recently to have OID use its own i/o routines.
- Thomas
> Not sure what to do about this. If you had actually typed 2^64-1040,
> it would be appropriate for the code to reject it. But I hadn't
> realized that the extra check would introduce a discrepancy between
> 32- and 64-bit machines for negative inputs. Maybe it'd be
> better just
> to delete
On Wed, 20 Dec 2000, Tom Lane wrote:
> Ryan Kirkpatrick <[EMAIL PROTECTED]> writes:
> > INSERT INTO OID_TBL(f1) VALUES ('-1040');
> > ERROR: oidin: error reading "-1040": value too large
>
> That's coming from a possibly-misguided error check that I put into
> oidin():
...
> On a 32-bit machine
ListAdmin: Ignore the stalled/delayed posts from me earlier.
Accidently posted with the wrong from address :(
On Wed, 20 Dec 2000, Tom Lane wrote:
> Ryan Kirkpatrick <[EMAIL PROTECTED]> writes:
> > INSERT INTO OID_TBL(f1) VALUES ('-1040');
> > ERROR: oidin: error reading "-1040": va
> Ryan Kirkpatrick <[EMAIL PROTECTED]> writes:
> > INSERT INTO OID_TBL(f1) VALUES ('-1040');
> > ERROR: oidin: error reading "-1040": value too large
>
> That's coming from a possibly-misguided error check that I put into
> oidin():
>
> unsigned long cvt;
> char *endptr;
>
>
From: "Ryan Kirkpatrick" <[EMAIL PROTECTED]>
> On Sat, 16 Dec 2000, Bruce Momjian wrote:
>
> > Here is the list of features in 7.1.
>
> One thing that I think ought to be added is that with 7.1,
> PostgreSQL will compile out of the box (i.e. without any extra patches)
> for Linux/Alpha.
What pa
Ryan Kirkpatrick <[EMAIL PROTECTED]> writes:
> INSERT INTO OID_TBL(f1) VALUES ('-1040');
> ERROR: oidin: error reading "-1040": value too large
That's coming from a possibly-misguided error check that I put into
oidin():
unsigned long cvt;
char *endptr;
cvt = strt
I have had the time to test today's (12/19) snapshot on my
Linux/Alpha and the good news is that only two regression tests are
failing. The bad news is that these regression tests do not fail on
Linux/Intel. :( [1]
Specifically, the oid and misc regression tests failed. Here are
t
14 matches
Mail list logo
