[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] SWIG Policy Question
From: |
felix winkelmann |
Subject: |
Re: [Chicken-users] SWIG Policy Question |
Date: |
Tue, 11 Apr 2006 09:13:49 +0200 |
On 4/11/06, John Lenz <address@hidden> wrote:
> A test was recently added to the SWIG test suite that checks if overflows
> are correctly detected. It was added for guile, which allows arbitrarily
> big integers, so a check if the integer is inside the range of a long is
> possible. Since the scheme languages in SWIG share a lot of code, the
> test was added for chicken as well. But the test currently fails, and I
> am wondering how to proceed.
>
> Currently, SWIG chicken accepts either a fixnum or a flonum to any integer
> parameter, and does no checking at all for overflow. (It uses
> C_num_to_int to convert. Thus, a direct cast from int to double.)
>
> The question is, which types (if any) should SWIG check for overflow?
> Testing for the double/flonum -> long overflows could be made, using
> something like
> double arg1d = C_flonum_magnitude(scm1);
> if ((double)C_WORD_MIN > arg1d || (double)C_WORD_MAX < arg1d)
> SWIG_Chicken_Barf(...)
> int arg1 = (int) arg1d;
>
> Also, casts from fixnums to shorts could also be checked for overflow.
> Casts from fixnums to ints or longs would not check for overflow... since
> any overflow chicken would convert to a flonum.
>
> Or, we could skip overflow detection and leave the code like it is right
> now. In that case, I would remove the tests for overflow from the chicken
> portion of the test suite.
>
To be honest... Since we are interfacing with C/C++ code that gives
a hoot about overflow detection, why should we care on the Scheme side?
(Well, there a probably loads of reasons, but I don't see much need).
IMHO never mind the overflows.
> PS: I recently commited some changes to configure.in to no longer check
> chicken-config and use csc instead.
Thanks a lot. I was already wondering whether csc should be renamed,
something that I like to avoid at all costs... ;-)
cheers,
felix