Re: "cannot coerce inexact literal to fixnum"
Al <[email protected]>
| Newsgroups | gmane.lisp.scheme.chicken |
|---|---|
| Message-ID | <[email protected]> |
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.)