[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH][5] types.db entries for the overflow-aware

From: LemonBoy
Subject: Re: [Chicken-hackers] [PATCH][5] types.db entries for the overflow-aware ops
Date: Sun, 21 May 2017 20:12:42 +0200
User-agent: Mutt/1.8.2 (2017-04-18)

On Sun, May 21, 2017 at 06:25:09PM +0200, Peter Bex wrote:
> I don't really care that much about this, so unless others have similar
> concerns I think we can apply this change.
> However, they shouldn't be #:enforce; they don't raise an error when
> their types are fixnum or false, which is what enforce means: if the
> code goes beyond this expression, you may assume the input types are
> correct.

I know, I've added the #:enforce annotation because the result is either
C_SCHEME_FALSE or something that went trough C_fix so no matter what the input
is we _always_ get a result with the correct type...whether or not the result
has any meaning is a different topic :)
The same goes for the other procedures, there's a comment in types.db that reads
`;;XXX should these be enforcing?` so this has been already discussed before.
> I believe these procedures can be marked #:pure, though, since they
> don't have *any* side effects (except for fx/?, since it will raise an
> exception when dividing by zero).
> Speaking of which: can't all the other fixnum-specific procedures be
> pure as well?  Except for fx/, of course.
Of course, good catch.
> > - There's no way to distinguish the result of `(fx+? 'foo 3)` from the
> > result of an
> >  overflowing calculation, couple it with the lack of any warning and
> > you're in for a nice bug
> >  hunt.
> Speaking of strange bugs, I'm wondering whether these fixnum procedures
> should be foldable at all (that also goes for the procedures that are
> already in types.db).  Consider the case where you're compiling on a
> 64-bit machine.  The compiler folds the fixnum operations at
> compile-time, resulting in a fixnum.  However, if the fixnum is not
> representable as a fixnum on the target computer, it will be represented
> as a bignum (or on CHICKEN 4, as a flonum).
> This not only produces a different answer than when the same code would
> be compiled on the 32-bit machine and in the interpreter, but it also
> may trigger other unexpected behaviour resulting from a mismatch of the
> expectation that you're dealing with fixnums only.  For example, a
> specialised unsafe version of a generic procedure might end up being
> specialised for fixnums, but on a 32-bit platform it might still receive
> a bignum (or a flonum on master).
I think that's the right thing to do, too bad we can't check if the result of
the constant evaluation matches the expected type at compile time.
> Hm, I wonder if this stuff causes other problems as well...
> Anyway, attached is a signed-off version of your patch without
> the #:enforce and with the #:pure annotations, and a second patch
> which removes #:foldable from the other fixnum operations too.
> Cheers,
> Peter

reply via email to

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