Re: Re: int8 bug on Alpha - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: int8 bug on Alpha
Date
Msg-id 2987.985232351@sss.pgh.pa.us
Whole thread Raw
In response to Re: int8 bug on Alpha  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
List pgsql-hackers
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> For integers (optional sign and all digits), the code in
> src/backend/parser/scan.l uses strtol() to read the string, then checks
> for failure. If it fails, the number is interpreted as a double float on
> the assumption that if it could hold more digits it would succeed!

Ohhhh....

This is an Alpha, remember?  long *is* 64 bits on that machine,
therefore strtol is correct to accept the number.  Unfortunately,
later in the parser we assign the datatype int4, not int8, to the
"integer" constant, and so it gets truncated.  make_const is making
an unwarranted assumption that T_Integer is the same as int4 --- or,
if you prefer, make_const is OK and scan.l is erroneous to use
node type T_Integer for ints that exceed 32 bits.

This is a portability bug, no question.  But I'd expect it to fail
like that on all Alpha-based platforms.  Adriaan, when you say it
works on Linux, are you talking about Linux/Alpha or some other
hardware?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: Call for platforms
Next
From: Tom Lane
Date:
Subject: Re: BufferSync() & FlushRelationBuffers() conflict