headers
Ian Price | 9 Jul 2012 14:29
Gravatar

bug#11887: string->number edge cases


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 <at> (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 <at> (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
(Continue reading)

Permalink | Reply |
headers
Andy Wingo | 5 Mar 2013 15:49
Picon
Favicon

bug#11887: string->number edge cases

Hi Ian,

On Mon 09 Jul 2012 14:29, Ian Price <ianprice90 <at> googlemail.com> writes:

> PARSE ERROR         ("+InF.0" +inf.0 "+inf.0" "+Inf.0") => #f
> PARSE ERROR         ("-iNF.0" -inf.0 "-inf.0" "-Inf.0") => #f
> PARSE ERROR         ("+NAN.0" +nan.0 "+nan.0" "+NaN.0") => #f

These are not errors.  +NAN.0 is not even not a number :)

> PARSE ERROR         ("+nan.1" #f) => +nan.0
> PARSE ERROR         ("+nan.01" #f) => +nan.0

These are only supported because 2.0.0 was released with +nan.1 parsing
as +nan.0.  It signals a deprecation warning with a note to this effect.
Guile from master should pass these particular tests.

> PARSE ERROR         ("nan.0" #f) => +nan.0
> PARSE ERROR         ("inf.0" #f) => +inf.0
> PARSE ERROR         ("#e+nan.0" #f) => +nan.0
> PARSE ERROR         ("#e+inf.0" #f) => +inf.0
> PARSE ERROR         ("#e-inf.0" #f) => -inf.0

These are errors.

> If the number contains a division by zero, we get a numerical overflow
> error.
>
> scheme <at> (guile−user)> (string->number "3/0")
> ERROR: In procedure string−>number:
(Continue reading)

Permalink | Reply |
headers
Mark H Weaver | 5 Mar 2013 20:04

bug#11887: string->number edge cases

Andy Wingo <wingo <at> pobox.com> writes:

> On Mon 09 Jul 2012 14:29, Ian Price <ianprice90 <at> googlemail.com> writes:
>
>> If the number contains a division by zero, we get a numerical overflow
>> error.
>>
>> scheme <at> (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)'.
>
> This is also an error.  We should plumb through some extra arg to
> mem2ureal, I guess, to check for a zero denominator.

FYI, I produced a simple patch a while back to fix this (see below), but
it had an interesting side effect: it caused the reader to read things
like "3/0" and "4+3/0i" as symbols.  More generally, anything for which
'scm_string_to_number' returns false is treated as a symbol by 'read'.

I'm not sure how I feel about this.  What do you think?

     Mark

diff --git a/libguile/numbers.c b/libguile/numbers.c
index 66c95db..9013f0c 100644
--- a/libguile/numbers.c
+++ b/libguile/numbers.c
 <at>  <at>  -5809,7 +5809,7  <at>  <at>  mem2ureal (SCM mem, unsigned int *p_idx,
             return SCM_BOOL_F;
(Continue reading)

Permalink | Reply |
headers
Peter Bex | 5 Mar 2013 20:14
Picon
Picon
Favicon

bug#11887: string->number edge cases

On Tue, Mar 05, 2013 at 02:04:55PM -0500, Mark H Weaver wrote:
> FYI, I produced a simple patch a while back to fix this (see below), but
> it had an interesting side effect: it caused the reader to read things
> like "3/0" and "4+3/0i" as symbols.  More generally, anything for which
> 'scm_string_to_number' returns false is treated as a symbol by 'read'.

I think this is simple and at least internally consistent.  Several
Schemes assume something like 1/0 is a symbol; Chicken does this as
well, with the numbers egg loaded, so does Gambit.

Raising an error is also acceptable.  According to the lexical syntax
1/0 *is* a valid number, so you could argue that it *must* parse as
a number, which is impossible so an error should occur.

This is also related to how string->number deals with it; if it
returns #f it is essentially saying "this is not valid numerical syntax"
and should fail to parse as a number.  Not raising an exception on
(string->number "1/0) but raising an exception on
(with-input-from-string "1/0" read) is a bit odd, I'd say.

Cheers,
Peter
--

-- 
http://www.more-magic.net
Permalink | Reply |
headers
Mark H Weaver | 6 Mar 2013 19:11

bug#11887: string->number edge cases

Hi Peter,

Peter Bex <Peter.Bex <at> xs4all.nl> writes:

> On Tue, Mar 05, 2013 at 02:04:55PM -0500, Mark H Weaver wrote:
>> FYI, I produced a simple patch a while back to fix this (see below), but
>> it had an interesting side effect: it caused the reader to read things
>> like "3/0" and "4+3/0i" as symbols.  More generally, anything for which
>> 'scm_string_to_number' returns false is treated as a symbol by 'read'.
>
> I think this is simple and at least internally consistent.  Several
> Schemes assume something like 1/0 is a symbol; Chicken does this as
> well, with the numbers egg loaded, so does Gambit.
[...]
> This is also related to how string->number deals with it; if it
> returns #f it is essentially saying "this is not valid numerical syntax"
> and should fail to parse as a number.  Not raising an exception on
> (string->number "1/0) but raising an exception on
> (with-input-from-string "1/0" read) is a bit odd, I'd say.

Thanks, this makes me feel somewhat better about it.  I guess it's okay.

> On Tue, Mar 05, 2013 at 03:49:13PM +0100, Andy Wingo wrote:
> > Hi Ian,
> > 
> > On Mon 09 Jul 2012 14:29, Ian Price <ianprice90 <at> googlemail.com> writes:
> > 
> > > PARSE ERROR         ("+InF.0" +inf.0 "+inf.0" "+Inf.0") => #f
> > > PARSE ERROR         ("-iNF.0" -inf.0 "-inf.0" "-Inf.0") => #f
> > > PARSE ERROR         ("+NAN.0" +nan.0 "+nan.0" "+NaN.0") => #f
(Continue reading)

Permalink | Reply |
headers
Mark H Weaver | 6 Mar 2013 19:15

bug#11887: [PATCH] Improve standards conformance of string->number (was Re: bug#11887: string->number edge cases)

Here's a patch to fix these problems.  Comments and suggestions welcome.

    Mark
Attachment (0001-Improve-standards-conformance-of-string-number.patch): text/x-diff, 6468 bytes
Permalink | Reply |
headers
Mark H Weaver | 7 Mar 2013 21:47

bug#11887: [PATCH] Improve standards conformance of string->number (was Re: bug#11887: string->number edge cases)

I wrote:
> Here's a patch to fix these problems.  Comments and suggestions welcome.

I went ahead and pushed this to stable-2.0.  I'm closing this bug.

    Thanks,
      Mark
Permalink | Reply |
headers
Peter Bex | 5 Mar 2013 20:06
Picon
Picon
Favicon

bug#11887: string->number edge cases

On Tue, Mar 05, 2013 at 03:49:13PM +0100, Andy Wingo wrote:
> Hi Ian,
> 
> On Mon 09 Jul 2012 14:29, Ian Price <ianprice90 <at> googlemail.com> writes:
> 
> > PARSE ERROR         ("+InF.0" +inf.0 "+inf.0" "+Inf.0") => #f
> > PARSE ERROR         ("-iNF.0" -inf.0 "-inf.0" "-Inf.0") => #f
> > PARSE ERROR         ("+NAN.0" +nan.0 "+nan.0" "+NaN.0") => #f
> 
> These are not errors.  +NAN.0 is not even not a number :)

I double-checked, but in the upcoming R7RS it is (see 7.1, paragraph 2 of
draft 7).  It looks like R6RS was case-sensitive in its numerical syntax
and +NAN.0 is disallowed by it.

Cheers,
Peter
--

-- 
http://www.more-magic.net
Permalink | Reply |

Gmane