GNU bug report logs - #79938
A version of string-to-num that returns NIL on a parsing failure

Previous Next

To reply to this bug, email your comments to 79938 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: matthewktromp <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: A version of string-to-num that returns NIL on a parsing failure
Date: Tue, 02 Dec 2025 17:37:54 -0500

[Message part 1 (text/plain, inline)]

Tags: patch

Currently, there isn't a good way to parse something that may or may not
be a number.  Since string-to-number returns 0 when the string cannot be
parsed as a number, it's impossible to distinguish non-number strings
from 0.  This makes it hard to write robust parsing logic.  See, for
instance, this stackexchange question, and the (rather convoluted)
regexes people suggest:
https://emacs.stackexchange.com/questions/75388/how-can-i-check-whether-a-string-represents-a-number-in-elisp

This patch adds a function, string-to-number-checked, which is identical
to string-to-number, but it returns NIL instead of 0 when the string
cannot be parsed as a number.


In GNU Emacs 30.1.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.18.2, Xaw3d scroll bars)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101018
System Description: NixOS 25.05 (Warbler)

Configured using:
 'configure
 --prefix=/nix/store/yffwm14bwi3vask5wfx6pcrdgxck61ba-emacs-30.1
 --disable-build-details --with-modules --with-x-toolkit=lucid
 --with-cairo --with-xft --with-compress-install
 --with-toolkit-scroll-bars --with-native-compilation
 --without-imagemagick --with-mailutils --without-small-ja-dic
 --with-tree-sitter --with-xinput2 --without-xwidgets --with-dbus
 --with-selinux'

[0001-Add-string-to-num-checked.patch (text/patch, attachment)]

Message #8 received at 79938 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: matthewktromp <at> gmail.com, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Sean Whitton <spwhitton <at> spwhitton.name>, Andrea Corallo <acorallo <at> gnu.org>
Cc: 79938 <at> debbugs.gnu.org
Subject: Re: bug#79938: A version of string-to-num that returns NIL on a
 parsing failure
Date: Wed, 03 Dec 2025 14:52:46 +0200

> From: matthewktromp <at> gmail.com
> Date: Tue, 02 Dec 2025 17:37:54 -0500
> 
> Currently, there isn't a good way to parse something that may or may not
> be a number.

What about

  (numberp (read STREAM))

?

> This patch adds a function, string-to-number-checked, which is identical
> to string-to-number, but it returns NIL instead of 0 when the string
> cannot be parsed as a number.

If 'read' cannot be a solution, I think I'd prefer adding a new
optional argument to string-to-number instead of adding yet another
primitive.

What do others think?

Message #11 received at 79938 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>, matthewktromp <at> gmail.com,  Stefan Monnier
 <monnier <at> iro.umontreal.ca>,  Andrea Corallo <acorallo <at> gnu.org>,
 79938 <at> debbugs.gnu.org
Subject: Re: bug#79938: A version of string-to-num that returns NIL on a
 parsing failure
Date: Wed, 03 Dec 2025 13:06:16 +0000

Hello,

On Wed 03 Dec 2025 at 02:52pm +02, Eli Zaretskii wrote:

>> From: matthewktromp <at> gmail.com
>> Date: Tue, 02 Dec 2025 17:37:54 -0500
>>
>> Currently, there isn't a good way to parse something that may or may not
>> be a number.
>
> What about
>
>   (numberp (read STREAM))
>
> ?
>
>> This patch adds a function, string-to-number-checked, which is identical
>> to string-to-number, but it returns NIL instead of 0 when the string
>> cannot be parsed as a number.
>
> If 'read' cannot be a solution, I think I'd prefer adding a new
> optional argument to string-to-number instead of adding yet another
> primitive.
>
> What do others think?

I agree that a new optional argument is preferable.

That's how CL does it --

    (parse-integer s :junk-allowed t)

':junk-allowed t' is what Emacs's does by default at present, so the
new option would be to disallow junk.

-- 
Sean Whitton

Message #14 received at 79938 <at> debbugs.gnu.org (full text, mbox):

From: Matthew Tromp <matthewktromp <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79938 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Andrea Corallo <acorallo <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79938: A version of string-to-num that returns NIL on a
 parsing failure
Date: Wed, 3 Dec 2025 19:20:54 -0500

[Message part 1 (text/plain, inline)]

> If 'read' cannot be a solution, I think I'd prefer adding a new
> optional argument to string-to-number instead of adding yet another
> primitive.

That's reasonable.

> That's how CL does it --
>
>     (parse-integer s :junk-allowed t)
>
> ':junk-allowed t' is what Emacs's does by default at present, so the
> new option would be to disallow junk.

This isn't quite correct.  According to this CL reference I found:
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_parse-integer.html

"The first value returned is either the integer that was parsed, or else
nil if no syntactically correct integer was seen but junk-allowed was true."

This is the behavior of the "string-to-number-checked" I wrote.  Currently,
when no syntactically correct number is seen, string-to-number returns 0,
rather than nil.

I think that, in most situations where you would use string-to-number,
getting nil instead of 0 is preferable.  Even if you don't explicitly
handle that case, you're more likely to get an early error when using the
value (like when adding it to another number), which allows you to notice
something's wrong sooner and more easily.

The underlying string_to_number c function actually does this.
string-to-number specifically checks if the value returned from
string_to_number was nil, and returns a 0 in that case, discarding
potentially useful information for no clear reason.

[Message part 2 (text/html, inline)]

Message #17 received at 79938 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Matthew Tromp <matthewktromp <at> gmail.com>
Cc: 79938 <at> debbugs.gnu.org, acorallo <at> gnu.org, monnier <at> iro.umontreal.ca,
 spwhitton <at> spwhitton.name
Subject: Re: bug#79938: A version of string-to-num that returns NIL on a
 parsing failure
Date: Thu, 04 Dec 2025 10:42:38 +0200

> From: Matthew Tromp <matthewktromp <at> gmail.com>
> Date: Wed, 3 Dec 2025 19:20:54 -0500
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 
> 	Andrea Corallo <acorallo <at> gnu.org>, 79938 <at> debbugs.gnu.org
> 
> I think that, in most situations where you would use string-to-number, getting nil instead of 0 is preferable. 

That might or might not be so, but in any case we cannot make such
backward-incompatible changes in a function that behaved differently
since about forever.  (And I guess the current behavior is also
useful, or else the persons who wrote string-to-number wouldn't have
chosen it to begin with.  For starters, some Lisp programs could
assume that the return value is always a number.)

> Even if you don't explicitly handle that case, you're more likely to get an early error when using the value
> (like when adding it to another number), which allows you to notice something's wrong sooner and more
> easily.
> 
> The underlying string_to_number c function actually does this.  string-to-number specifically checks if the
> value returned from string_to_number was nil, and returns a 0 in that case, discarding potentially useful
> information for no clear reason. 

See above for a possibly "clear reason".

Message #20 received at 79938 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Matthew Tromp <matthewktromp <at> gmail.com>
Cc: Andrea Corallo <acorallo <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
 79938 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79938: A version of string-to-num that returns NIL on a
 parsing failure
Date: Thu, 04 Dec 2025 10:18:26 +0000

Hello,

On Wed 03 Dec 2025 at 07:20pm -05, Matthew Tromp wrote:

> This isn't quite correct.  According to this CL reference I found:
> http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_parse-integer.html
>
>
> "The first value returned is either the integer that was parsed, or else nil if no
> syntactically correct integer was seen but junk-allowed was true."

Thanks, I misremembered exactly how it works.  My basic point was that
an optional argument is used to decide how lenient to be about
non-digits in the input.

> This is the behavior of the "string-to-number-checked" I wrote.  Currently, when
> no syntactically correct number is seen, string-to-number returns 0, rather than
> nil.
>
> I think that, in most situations where you would use string-to-number, getting nil
> instead of 0 is preferable.  Even if you don't explicitly handle that case, you're
> more likely to get an early error when using the value (like when adding it to
> another number), which allows you to notice something's wrong sooner and more
> easily.
>
> The underlying string_to_number c function actually does this.  string-to-number
> specifically checks if the value returned from string_to_number was nil, and
> returns a 0 in that case, discarding potentially useful information for no clear
> reason.

There's not much point in discussing this because, as Eli says, we're
constrained by backwards compatibility.

I don't think you've shared a view on whether the 'read' solution
suffices?  Does it satisfy your use case?

-- 
Sean Whitton

Message #23 received at 79938 <at> debbugs.gnu.org (full text, mbox):

From: Matthew Tromp <matthewktromp <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Andrea Corallo <acorallo <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
 79938 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79938: A version of string-to-num that returns NIL on a
 parsing failure
Date: Thu, 4 Dec 2025 11:11:39 -0500

[Message part 1 (text/plain, inline)]

> That might or might not be so, but in any case we cannot make such
> backward-incompatible changes in a function that behaved differently
> since about forever.

Yeah, I'm definitely not suggesting making a backwards-incompatible
change.  My point is just that this is a useful thing to offer users.

> Thanks, I misremembered exactly how it works.  My basic point was that
> an optional argument is used to decide how lenient to be about
> non-digits in the input.

Makes sense.  I just wanted to make sure you understood exactly what I'm
describing.  Although an option for some kind of "strict" checking which
returns nil for numbers with trailing garbage, similar to what
:junk-allowed controls in CL, also strikes me as a good idea.

> I don't think you've shared a view on whether the 'read' solution
> suffices?  Does it satisfy your use case?

read has a few problems.
- Since read continues until it reaches the end of a symbol/sexp, it could
potentially continue reading until the end of the given string.
string-to-number stops as soon as it finds something that's not a number,
which is more performant.
- When read finds something that could be a symbol, it interns it, which
wastes cycles and consumes memory - potentially a lot of it, as described
above - forever (if I understand symbol interning in emacs correctly).
- It doesn't have the same semantics for trailing garbage.
(string-to-number "12ab") returns 12, whereas (read "12ab") returns the
symbol '12ab.

On Thu, Dec 4, 2025 at 5:18 AM Sean Whitton <spwhitton <at> spwhitton.name>
wrote:

> Hello,
>
> On Wed 03 Dec 2025 at 07:20pm -05, Matthew Tromp wrote:
>
> > This isn't quite correct.  According to this CL reference I found:
> >
> http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_parse-integer.html
> >
> >
> > "The first value returned is either the integer that was parsed, or else
> nil if no
> > syntactically correct integer was seen but junk-allowed was true."
>
> Thanks, I misremembered exactly how it works.  My basic point was that
> an optional argument is used to decide how lenient to be about
> non-digits in the input.
>
> > This is the behavior of the "string-to-number-checked" I wrote.
> Currently, when
> > no syntactically correct number is seen, string-to-number returns 0,
> rather than
> > nil.
> >
> > I think that, in most situations where you would use string-to-number,
> getting nil
> > instead of 0 is preferable.  Even if you don't explicitly handle that
> case, you're
> > more likely to get an early error when using the value (like when adding
> it to
> > another number), which allows you to notice something's wrong sooner and
> more
> > easily.
> >
> > The underlying string_to_number c function actually does this.
> string-to-number
> > specifically checks if the value returned from string_to_number was nil,
> and
> > returns a 0 in that case, discarding potentially useful information for
> no clear
> > reason.
>
> There's not much point in discussing this because, as Eli says, we're
> constrained by backwards compatibility.
>
> I don't think you've shared a view on whether the 'read' solution
> suffices?  Does it satisfy your use case?
>
> --
> Sean Whitton
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.