bugfix: include most negative two's in cnum range.

The INT_PTR_MIN value isn't the smallest value actually
representable in cnum, because it is just the additive
inverse of INT_PTR_MAX. In two's complement, the INT_PTR_MIN-1
value is still representable. But we are excluding it.
If a Lisp integer has the value INT_PTR_MIN-1, the c_num
function will fail to convert it to a cnum.
This situation occurs in FFI, where code may expect that the
Lisp value #x-80000000 can convert to an external 32 bit
integer type.  This will be done by way of a conversion to
cnum first via c_num (see ffi_i32_put for instance, which
calls c_i32 which relies on c_num).

* arith.c (INT_PTR_MAX_SUCC_MP): New static variable.
This holds a bignum equivalent to INT_PTR_MAX + 1.
(in_int_ptr_range): We now check whether the value
against the range [-(INT_PTR_MAX + 1), (INT_PTR_MAX + 1)]
and then check all possible return values. The MP_LT
case is clearly in range, and MP_GT is out of the range.
The interesting situation is MP_EQ: in that case
we just test the sign to see whether we are looking
at -(INT_PTR_MAX + 1).
(int_flo): INT_PTR_MIN is referenced in this function, so
we use INT_PTR_MIN - 1 instead. This allows that value
to be handled via the simple bignum(n) case.
(arith_init): Initialize INT_PTR_MAX_SUCC_MP. We cannot
initialize it to INT_PTR_MAX + 1 directly because that
expression overflows: insted we use INT_PTR_MIN - 1 and
then flip the resulting bignum's sign.
(arith_free_all): Call mp_clear on the new variable to
release its digit buffer.

* ffi.c (make_ffi_type_enum): Use INT_PTR_MIN - 1 as the
initial value of the highest variable, to accurately
calculate the range of the enum values if they contain
INT_PTR_MIN - 1.

0 files changed, 0 insertions, 0 deletions