bugfix: c_num won't convert most negative value.

This bug causes a problem particularly in FFI. THe conversion
of an integer to the FFI int type begins by conversion via
c_num to the cnum type, which is at least as wide as int.
Alas, the INT_MIN value (e.g. #x-80000000 on 32 bits) will
not convert!

Fixing this has a ripple effect. We alter the INT_PTR_MIN
constant to include this value. This causes the derived
NUM_MIN to also include the extra negative value, extending
the fixnum range by one value. Everything seems to be okay.

* configure: Decrease value of INT_PTR_MIN and
DOUBLE_INTPTR_MIN constants by one to include the most
negative two's complement value.

* ffi.c (make_ffi_type_enum): We must not subtract 1 from
INT_PTR_MIN here any more.

* mpi.c (mp_in_range): If the bignum is negative, then extend
the range check by one value, so that we don't reject the
most negative two's complement value.

1 files changed, 1 insertions, 1 deletions

diff --git a/ffi.c b/ffi.c
index 7dd5b9e5..61551228 100644
--- a/ffi.c
+++ b/ffi.c
@@ -3018,7 +3018,7 @@ static val make_ffi_type_enum(val syntax, val enums,
   val num_sym = make_hash(nil, nil, nil);
   val obj = cobj(coerce(mem_t *, tft), ffi_type_s, &ffi_type_enum_ops);
   cnum lowest = INT_PTR_MAX;
-  cnum highest = INT_PTR_MIN - 1;
+  cnum highest = INT_PTR_MIN;
   cnum cur = -1;
   ucnum count = 0;
   val iter;