[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] Don't silently truncate huge literals, and
From: |
Peter Bex |
Subject: |
Re: [Chicken-hackers] [PATCH] Don't silently truncate huge literals, and don't constant-fold if it would result in such a literal |
Date: |
Mon, 1 Feb 2016 22:24:24 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Sat, Jan 30, 2016 at 03:07:37PM +0100, Peter Bex wrote:
> The attached patch detects such large literals and aborts the
> compilation (there's not much we can do in such a situation).
> Because the big-prime actually isn't an object literal occuring in the
> source code, we can avoid this particular case by refusing to constant-
> fold if the result would be too large to be encoded.
OK, as it turns out my patch was pretty broken, but the compiler didn't
complain because almost everything in constant-form-eval is wrapped in
a "handle-exceptions" clause, so even legitimate errors in the compiler
would not be caught.
I've now reflowed the code so that only exceptions in the actual
evaluation of the form itself will be caught. Others will raise
an exception like they should. This immediately found a few bugs
in my code, but also in the compiler *as it was*: in some situations,
constant-form-eval will RECEIVE a node tree as "results" instead of
a list. I don't fully grok this, so I've simply keps it the way it
was and added a TODO. It's a separate bug that's been in there for
probably ages already, and we can fix it independently.
Another thing that went wrong was that the test didn't work on 32 bit
systems, because on 32 bit systems objects have only 24 "length" bits!
This means the test's hex number->string conversion would fail both at
compile time *and* at run time. I've now handled this by wrapping the
number->string call in an exception handler. It's a bit ugly, but less
fiddly than trying to duplicate the tricky string size calculation
(including the rounding up as we do in C, and the accounting for the sign
in negative numbers) in Scheme. It would be especially tricky to fully
test this too, so just handling the out of bounds exception raised by
make-vector is better.
Cheers,
Peter
0001-Don-t-silently-truncate-huge-literals.chicken-5.patch
Description: Text Data
0001-Don-t-silently-truncate-huge-literals.master.patch
Description: Text Data
signature.asc
Description: Digital signature
- Re: [Chicken-hackers] [PATCH] Don't silently truncate huge literals, and don't constant-fold if it would result in such a literal,
Peter Bex <=