On 2024-02-10 02:42, Al wrote:
... if I enable fixnum, csc chokes on both the third and fourth
display's with: "Error: cannot coerce inexact literal `2147483647' to
fixnum". It compiles and runs fine if those lines are commented out
(or if fixnum is disabled).
So the error comes from a check for (big-fixnum?) in
chicken-core/core.scm. It is defined in chicken-core/support.scm:
(define (big-fixnum? x) ;; XXX: This should probably be in c-platform
(and (fixnum? x)
(feature? #:64bit)
(or (fx> x 1073741823)
(fx< x -1073741824) ) ) )
(define (small-bignum? x) ;; XXX: This should probably be in c-platform
(and (bignum? x)
(not (feature? #:64bit))
(fx<= (integer-length x) 62) ) )
Maybe the condition in big-fixnum should be negated? Apply the
restrictive #x3fffffff limit only when NOT (feature? #:64bit) ?
Also, I've looked at Ken's number-limits egg. It has
#define MOST_POSITIVE_INT32 ((int32_t) 0x3fffffffL)
I don't know why this (as opposed to 0x7fffffff) would apply to #:64bit
installs..? In any case the documentation on call-cc.org says
* most-negative-integer32
Smallest negative int32_t value
* most-positive-integer32
Largest negative (sic!) int32_t value
... which is ALSO wrong for most-positive-integer32 , but it does refers
to int32_t, as opposed to chicken's internal representation (which uses
up an extra bit.)
