Hi guilers,

I've mentioned these to Mark Weaver on IRC off-hand before, but I'm
posting this bug report to "formalise" it, and make sure we don't
forget.

Peter Bex, as one of the maintainers of the chicken "numbers" egg,
created a thorough test suite for string->number a while ago[0], and it
points out a number of possible and actual errors in the handling of
string->number.

I've attached a copy with the modifications for guile already applied,
and a copy of the full results, but the summary is as follows.

If the number contains a division by zero, we get a numerical overflow
error.

scheme@(guile−user)> (string->number "3/0")
ERROR: In procedure string−>number:
ERROR: Throw to key `numerical−overflow' with args `("make−ratio" "Numerical overflow" #f #f)'.

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile−user) [1]> ,q

This contradicts the r6rs specification[1], which mandates a return
value of #f. IMO, this is the correct behaviour, since otherwise, we
have created a special case in the API for one type of invalid number.

(These tests cause the program to stop, and so are commented out in the
attached version.)

The rest of the errors are less serious, and show that we treat nans and
infinity someone inconsistently in guile. Specifically, we are strict on
case, and lenient on the numerical prefix.

0. http://bugs.call-cc.org/browser/release/4/numbers/trunk/tests/string-conversion.scm
1. http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_idx_584

Peter,

Thanks for these

-- 
Ian Price

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"