(< +nan.0 n) was yielding #t for fixnum n, and similarly for
(<= +nan.0 n) and (> n +nan.0) and so on. This also caused
(negative? +nan.0) to return #t.
It just happened that NaNs were less than all fixnums: if a
conditional was written the other way around then NaNs would
have been greater than all fixnums instead.
The flonum case was sort of "accidentally" correct, but if a
conditional was written the other way around then NaNs would
be both less than or equal to and greater than all or equal
to all flonums (but still not equal).
For both cases check for NaNs after getting the flonum values.
There were few things that prevented successful compilation
using c89 standard. (and other c* standards in case of gcc).
Fix them in this small patch.
Changes in 27/rand.c:
- Use __GNU_SOURCE__ instead of __GNU_LIBRARY__
or else any of -std=c* options don't work with gcc
- Add a check before using rand_r() as suggested in rand_r(3)
- Move _WIN_32 definitions to "else" branch because it uses the most portable version
sexp_double_to_ratio_2, which converts without introducing
round-off errors the way sexp_double_to_ratio does when it
multiplies by 10.
Changed sexp_inexact_to_exact to use this new function when
a non-zero fractional part of the input exists.
Try to fix win32 port. Now it runs both on Win32/Win64.
Win64 port currently depends on 128bits arithmetic thus it does not run on
MSVC.
Makefile now have EXCLUDE_POSIX_LIBS knob to exclude posix related library
from build.
Introduce msys PLATFORM for Makefile.detect to use MSYS's POSIX
emulation layer. It is intended for linking against MSYS tools; it is
not for embedding to Win32 applications.
Previous code was losing the carry bit in 'all ones' case, when adata[i]
= bdata[i] = SEXP_UINT_T_MAX, and carry = 1 too. In this case expression
(SEXP_UINT_T_MAX - bdata[i] - carry) overflows and yields an incorrect
value SEXP_UINT_T_MAX which results into carry being incorrectly set to
0 after addition.
We need to avoid the second overflow when calculating the new value of
the carry bit. One way to do this is at first check for the overflow in
(adata[i] + bdata[i]), and then throw in the (previous) carry bit.
I have also given "n" more expressive name and added a comment about
the reason why we need that temporary variable.
Naturally, fixed-width integer arithmetics can overflow. Chibi handles
it pretty well in general, but one case was missing: it is negation of
the minimal negative number that can be represented as a fixnum. That is,
sexp_fx_neg() must not be applied to sexp_make_fixnum(SEXP_MIN_FIXNUM)
because it overflows and returns an identical fixnum back.
sexp_fx_neg() itself seems to be used right in the current code, but
sexp_fx_abs()--which is defined in terms of sexp_fx_neg()--could be
applied to the forbidden number when used to retrieve an unboxed value
via the sexp_unbox_fixnum(sexp_fx_abs(x)) pattern. So I have added a
separate macro that safely calculates unboxed absolute value of a fixnum,
and replaced sexp_unbox_fixnum(sexp_fx_abs(x)) usages with it.
Current implementation uses two-bit tag for fixnums, plus we need one
bit for the sign, so fixnums have (machine word - 3) significant bits.
Regression tests cover word sizes of 16, 32, 64, and 128 bits (for the
sake of past- and future-proofness).
sexp_bignum_expt() does not have a regression test because we need to
check it with negative exponents like -2^29, so the base must be over
at least 2^(2^29) for the differences to be visible. Fun fact: bignum
representation of such number takes around 1/32 of the available user-
space memory, which makes testing on anything except 32-bit systems
unreasonable (4 TB of RAM anyone?)
