[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: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH][5] types.db entries for the overflow-aware ops
Date: Sun, 21 May 2017 20:28:12 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Sun, May 21, 2017 at 08:12:42PM +0200, LemonBoy wrote:
> On Sun, May 21, 2017 at 06:25:09PM +0200, Peter Bex wrote:
> > 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 :)

This issue is a bit more subtle than that.  Let's take this program:

(use (chicken fixnum))

(let* ((a (read))
       (b (read))
       (x (fx+? a b)))
  (when (and a b)
    (print (+ a b) " " x))) ;; + gets rewritten to C_a_i_fixnum_plus

If you compile and run this, and enter two numbers that aren't fixnums,
you'll get nonsense output instead of the addition followed by #f.

The reason is, if fx+? is enforcing, the code cannot possibly reach
the (+ a b) call, because it would have thrown an exception.  Therefore,
the type of a and b must be (or fixnum false).  Obviously this is
incorrect if the procedure doesn't bail out on bad argument types.

> 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 think Felix put that in there originally.  I certainly don't recall
a discussion about it.


Attachment: signature.asc
Description: Digital signature

reply via email to

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