Re: Re: int8 bug on Alpha

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: int8 bug on Alpha
Дата
Msg-id 2987.985232351@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: int8 bug on Alpha  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
Список 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 по дате отправления:

Предыдущее
От: Larry Rosenman
Дата:
Сообщение: Re: Call for platforms
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BufferSync() & FlushRelationBuffers() conflict