I've just stepped through the Klapperich bug - for those of you
who are not aware of it, the new algorithms in Dialect 3 that
check for numeric overflow are questionable, and an overflow on
division with the divisor less than zero is not caught. The
precise Klapperich bug is this:

SQL> select cast (-70000 as numeric (18,5)) / cast (1.95583 as numeric (18,5))
CON> from rdb$database;


=====================

1936.2502338333

SQL>

Note the improbability of dividing a negative number by a positive
number and achieving a positive result.

The cause is an undetected and unreported truncation. That is,
for me, a priority 1 bug. I'd rather see the server crash than
return the wrong answer.

This must be fixed (my opinion) - the question is how.

The problem can be solved in one of two ways - improving the
algorithm so it correctly detects and reports overflow or
"promoting" all calculations that might overflow to double
precision. The InterBase group chose to report an overflow
unless one of the operands were cast to double precision.

Prior to V6, all suspect computations were done in double
precision and converted back to the original datatype if
possible. For Dialect 3, the InterBase group chose to report
an overflow if both operands are int64 and the operation
could create an internal overflow if performed in int64.

We can fix this particular test so the computation returns an
error or we can go back to performing computations in double
precision. One problem with fixing this particular test is
that the same guy who blew this computation wrote all the rest
of the boundary tests. Another is that we will return errors
for computations that can be done in double precision and return
correct results. The major problem with "promoting" the
computation to double precision is that it is a couple of
bits less precise than int64 - if the computation works in
int64.

Being tired, cranky and in the wrong time zone, I don't have
an answer and would like to hear opinions.


Ann