Re: int8 & INT64_IS_BUSTED
От | Florian G. Pflug |
---|---|
Тема | Re: int8 & INT64_IS_BUSTED |
Дата | |
Msg-id | 46D5FC15.7010505@phlo.org обсуждение исходный текст |
Ответ на | Re: int8 & INT64_IS_BUSTED (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: int8 & INT64_IS_BUSTED
|
Список | pgsql-hackers |
Tom Lane wrote: > "Florian G. Pflug" <fgp@phlo.org> writes: >> I'm confused about whether int8s work on a machine on which >> INT64_IS_BUSTED. My reading of the code suggests that int8 >> will be available, but be, well, busted in such a machine. > > The datatype exists, but it's really only int32. > >> For example, int8mul seems as if I'd just return the wrong >> answer on such a machine. > > Well, obviously it's gonna overflow sooner than you'd think, but it will > give valid answers as long as you never try to compute a value that > doesn't fit in int32; and it will correctly complain if you do. I still think int8mul is buggy. It calculates result as arg1 * arg2, and then checks for an overflow by dividing again, and seeing if the right answer comes out. Which sounds good. But it *skips* that check if both arguments fit into an int32 - check is (arg1 == (int64) ((int32) arg1) && arg2 == (int64) ((int32) arg2)). Which for INT64_IS_BUSTED seems to be equivalent to (arg1 == arg1 && arg2 == arg2), and thus the check will never fire in that case. I didn't test this though - so maybe I'm just reading it wrong. greetings, Florian Pflug
В списке pgsql-hackers по дате отправления: