Re: Re: int8 bug on Alpha

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: lockhart(at)fourpalms(dot)org
Cc: Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>, Postgresql <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: int8 bug on Alpha
Date: 2001-03-22 03:39:11
Message-ID: 2987.985232351@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-03-22 03:47:31 Re: BufferSync() & FlushRelationBuffers() conflict
Previous Message Larry Rosenman 2001-03-22 03:31:09 Re: Call for platforms