chicken-hackers
[Top][All Lists]
Advanced

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

[Chicken-hackers] [PATCH] Fix panic in decode_literal() on flonum litera


From: Peter Bex
Subject: [Chicken-hackers] [PATCH] Fix panic in decode_literal() on flonum literals
Date: Sun, 18 Sep 2011 18:27:07 +0200
User-agent: Mutt/1.4.2.3i

Hi again,

Christian and I independently found a bug triggered by the recent changes
in the number->string conversion routines.

When encoding a literal, the compiler uses the normal number-to-string
conversion procedures also used by display, printf etc.  but when reading
back these literals in runtime.c's decode_literal(), the libc functions
strtod() and strtol() are being used directly.

This causes a problem when the system procedures accept "+inf" or "+inf."
as valid syntax.  The decode_literal function advances the string pointer
to point after the last character consumed by strtod() or strtol().

When in the recursion step used when reading non-atomic literals (in the
default clause of the last switch in decode_literal2()), it is implicitly
assumed that decode_literal2 causes the string pointer to be moved after
the NUL character that terminates the flonum string.  However, this is
not the case in the situation where strtod accepts "+nan" or "+nan.".

Then when the next item is read, the panic is triggered because it's
still somewhere in the middle of a string.

After a while I realised that this problem might also show up in older
Chickens, during cross-compilation.  When the host system's libc prints
"+nan.0" and the target system's libc accepts "+nan.", there will also
be a panic.  The same is true when the host system emits numbers in a
syntax the target's libc doesn't accept.  So we should always use the
Chicken number reader and writer everywhere.

The attached patch (or changeset 96286a7a7144b17e4b7a3f08164fb6d6296f1722
in sjamaan-pending) fixes this problem by calling
convert_string_to_number() instead of strtol()/strtod().
I didn't really understand the purpose of the maybe_fixnum variable, so
I'd appreciate it if Felix or someone else who groks this can comment
on whether this fix is correct.

All the tests still pass, so if the maybe_fixnum is somehow relevant
there's a missing test.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

Attachment: 0001-Fix-decode_literal-not-to-use-system-functions-strto.patch
Description: Text document


reply via email to

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