[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 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... ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]