From 11b5c567124a61d8e8249a0fbcce47f2688573c6 Mon Sep 17 00:00:00 2001 From: Kaz Kylheku Date: Sat, 25 May 2019 22:03:54 -0700 Subject: 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. --- ffi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'ffi.c') 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; -- cgit v1.2.3