Re: [Chicken-hackers] [PATCH] Re: make check failing

[Peter Bex]

On Fri, Dec 28, 2012 at 12:22:04AM +0100, Felix wrote:
> > The real question is: what should happen?  Shouldn't all 64-bit
> > quantities be automatically converted from double to "long long" or
> > whatever it's called on 32 bit platforms?  The same will happen on
> > 64 bit platforms when using 63 or 64-bit numbers.  Maybe the regression
> > test should catch that, too.
> 
> Attached is a patch that corrects the behaviour of
> C_i_foreign_[unsigned]_integer64_argumentp (there where bugs in both
> the signed and unsigned variant).

Thanks!  A question though: Shouldn't C_i_foreign_integer64_argumentp
also check that the flonum is an integer (ie, there's nothing after the
decimal point)?

> I've disabled the test you added for
> 32-bit platforms - integer64 as return- or argument-type is only
> partially useful on 32-bit systems (in fact, it is mostly useless on
> all platforms, but we avoid compiler warnings and at least check and
> convert the values properly).

Yeah, they're effectively not 64-bit types but 52-bit types.

I think we should seriously consider supporting bignums in core.  They
won't add much extra overhead in terms of optimizations; the scrutinizer
already needs to consider the possibility that a fixnum overflows into a
flonum.  Overflowing into a bignum isn't much different.  In fact, it's
slightly more precise because you know that they're always integral,
while you lose that information when switching to flonums.  This at least
allows for some (admittedly trivial) optimizations you don't get when
using flonums, like knowing that integer? and exact? return true.

Besides, you won't lose information which helps srfi-4 64 bit types make
sense, and simplifies the part of the FFI currently under consideration.

Cheers,
Peter
-- 
http://sjamaan.ath.cx