This is a low priority fix, and needs not be tackled immediately. I'm just posting it now so that I don't forget about it later.
Debian's CI system caught a test failure on 32-bit architectures : the failing test expects the argument 100000000000 to be out of range. However, on 32-bit architectures, since 100000000000 is not a fixnum, but a bignum, the error produced is wrong-type-argument : in the primitive string-search, the correct type is tested before the correct range.
There are several ways to solve this :
extending the kind of accepted errors to include wrong-type-argument.
replacing 100000000000 with most-positive-fixnum, which is always a fixnum, and will therefore always produce the right error. This is what I did here, but you might prefer the other solution.
I'm also forwarding you this fix since github's CI could not possibly have caught this failure, for it runs the tests on only one architecture, x86_64.
Hello Daniel,
This is a low priority fix, and needs not be tackled immediately. I'm just posting it now so that I don't forget about it later.
Debian's CI system caught a test failure on 32-bit architectures : the failing test expects the argument
100000000000
to be out of range. However, on 32-bit architectures, since100000000000
is not afixnum
, but abignum
, the error produced iswrong-type-argument
: in the primitivestring-search
, the correct type is tested before the correct range.There are several ways to solve this :
wrong-type-argument
.100000000000
withmost-positive-fixnum
, which is always afixnum
, and will therefore always produce the right error. This is what I did here, but you might prefer the other solution.I'm also forwarding you this fix since github's CI could not possibly have caught this failure, for it runs the tests on only one architecture, x86_64.
Best,
Aymeric