Thread: int8 & INT64_IS_BUSTED

Hi

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.

For example, int8mul seems as if I'd just return the wrong
answer on such a machine.

Or are platforms with INT64_IS_BUSTED no longer supported,
and are all those #ifdefs only legacy code?

Please enlighten a poor linux+gcc user who can't remember
ever using a compiler without a "long long" datatype after
leaving TurboC under DOS.

greetings, Florian Pflug

On Wed, 2007-08-29 at 22:41 +0200, Florian G. Pflug wrote:
> Or are platforms with INT64_IS_BUSTED no longer supported,
> and are all those #ifdefs only legacy code?

Personally I think we should head in that direction: if we enable
integer datetimes by default in 8.4 (per earlier discussion), such
machines will be more broken still. We could fallback to using FP
datetimes on INT64_IS_BUSTED machines, but IMHO it is just fundamentally
unwise to have the behavior of a builtin data type dependent on this
sort of thing.

> Please enlighten a poor linux+gcc user who can't remember
> ever using a compiler without a "long long" datatype after
> leaving TurboC under DOS.

I'm not aware of any platform we might conceivably care about that
doesn't have a 64-bit integral type. To verify this, Peter E. suggested
that we emit a build-time warning if compiling on such a platform for
8.3, which I think would be worth doing.

-Neil

"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.

> Or are platforms with INT64_IS_BUSTED no longer supported,
> and are all those #ifdefs only legacy code?

There are people around here who think it's all useless legacy code,
but I'm not prepared to agree quite yet.  My position is that all the
core functionality should still work if INT64_IS_BUSTED.  You'll see
a surprisingly limited range for bigint, and pgstat counters will
overflow sooner than they otherwise would, and some other noncritical
problems.  But the database still works.
        regards, tom lane

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

"Florian G. Pflug" <fgp@phlo.org> writes:
> 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)).

Good point --- we should probably #ifdef out that part for
INT64_IS_BUSTED.
        regards, tom lane