unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Po Lu <luangruo@yahoo.com>, Richard Stallman <rms@gnu.org>
Cc: ulm@gentoo.org, eliz@gnu.org, contovob@tcd.ie, emacs-devel@gnu.org
Subject: Re: Lisp reader syntax and bootstrap
Date: Thu, 13 Jul 2023 15:07:43 -0700	[thread overview]
Message-ID: <5a110245-9b1c-be43-ca6e-2d37d3cac077@cs.ucla.edu> (raw)
In-Reply-To: <87y1jka126.fsf@yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

On 2023-07-12 21:27, Po Lu wrote:
> Lisp programmers should simply avoid using NaN and Inf

Support for NaN and Inf is ubiquitous nowadays, and it should be OK to 
write Emacs Lisp programs that use NaN and Inf, especially since Emacs 
itself uses them in its own Lisp files.

As I actually made money back in the 1970s writing code for VAXes, I was 
moved to look into RMS's suggestion to signal an error when reading 
"0.0e+NaN" on a VAX. Unfortunately this broke calculator.el - that is, I 
couldn't load calculator.el (or calculator.elc), as loading signaled an 
error when it saw the NaN. And even if we removed the NaN from 
calculator.el (and I suppose, infinities from other .el files), users 
would run into similar issues with their own code.

So I instead installed the attached patch. On a VAX this approximates 
infinities and NaNs with extremal values and non-numeric objects, 
respectively. Although I do not have a VAX to test it on, and am too 
lazy to spin up an emulator, I did test it on x86-64 by pretending that 
the x86-64 lacked IEEE support, and it seemed to work OK. (At least, I 
could load calculator.el....)

This patch shouldn't change behavior (or even the executable code) on 
today's platforms. It's purely for computer museums.

[-- Attachment #2: 0001-Port-NaN-infinity-handling-better-to-VAX.patch --]
[-- Type: text/x-patch, Size: 6370 bytes --]

From 0cd519971d199836ba0a6e9f0e36af9b9accaf0d Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 13 Jul 2023 14:26:29 -0700
Subject: [PATCH] Port NaN, infinity handling better to VAX

Nowadays .elc files routinely contain tokens like 1.0e+INF and
0.0e+NaN that do not work on antiques like the VAX that lack IEEE fp.
Port Emacs to these platforms, by treating infinities as extreme
values and NaNs as strings that trap if used numerically.
* src/lread.c (INFINITY): Default to HUGE_VAL if non-IEEE.
(not_a_number) [!IEEE_FLOATING_POINT]: New static array.
(syms_of_lread) [!IEEE_FLOATING_POINT]: Initialize it.
(read0): Report invalid syntax for +0.0e+NaN on platforms
that lack NaNs.
(string_to_number): On non-IEEE platforms, return HUGE_VAL
for infinity and a string for NaN.  All callers changed.
---
 doc/lispref/numbers.texi | 10 ++++++----
 etc/NEWS                 |  8 ++++++++
 src/data.c               |  3 ++-
 src/lread.c              | 29 ++++++++++++++++++++++++++---
 src/process.c            |  3 ++-
 5 files changed, 44 insertions(+), 9 deletions(-)

diff --git a/doc/lispref/numbers.texi b/doc/lispref/numbers.texi
index 3e45aa90fda..bcf89fc9ab1 100644
--- a/doc/lispref/numbers.texi
+++ b/doc/lispref/numbers.texi
@@ -270,10 +270,6 @@ Float Basics
 signs and significands agree.  Significands of NaNs are
 machine-dependent, as are the digits in their string representation.
 
-  NaNs are not available on systems which do not use IEEE
-floating-point arithmetic; if the read syntax for a NaN is used on a
-VAX, for example, the reader signals an error.
-
   When NaNs and signed zeros are involved, non-numeric functions like
 @code{eql}, @code{equal}, @code{sxhash-eql}, @code{sxhash-equal} and
 @code{gethash} determine whether values are indistinguishable, not
@@ -283,6 +279,12 @@ Float Basics
 conversely, @code{(equal 0.0 -0.0)} returns @code{nil} whereas
 @code{(= 0.0 -0.0)} returns @code{t}.
 
+  Infinities and NaNs are not available on legacy systems that lack
+IEEE floating-point arithmetic.  On a circa 1980 VAX, for example, the
+Lisp reader approximates an infinity with the nearest finite value,
+and a NaN with some other non-numeric Lisp object that provokes an
+error if used numerically.
+
 Here are read syntaxes for these special floating-point values:
 
 @table @asis
diff --git a/etc/NEWS b/etc/NEWS
index 5d5ea990b92..997f7e82c2b 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -585,6 +585,14 @@ behavior back for any other reason, you can do that using the
 previous behavior of showing 'U' in the mode line for 'koi8-u':
 
      (coding-system-put 'koi8-u :mnemonic ?U)
+
++++
+** Infinities and NaNs no longer act as symbols on non-IEEE platforms.
+On old platforms like the VAX that do not support IEEE floating-point,
+tokens like 0.0e+NaN and 1.0e+INF are no longer read as symbols.
+Instead, the Lisp reader approximates an infinity with the nearest
+finite value, and a NaN with some other non-numeric object that
+provokes an error if used numerically.
 \f
 * Lisp Changes in Emacs 30.1
 
diff --git a/src/data.c b/src/data.c
index 6de8e0cf1a1..5a31462d8ca 100644
--- a/src/data.c
+++ b/src/data.c
@@ -3033,7 +3033,8 @@ DEFUN ("string-to-number", Fstring_to_number, Sstring_to_number, 1, 2, 0,
     p++;
 
   Lisp_Object val = string_to_number (p, b, 0);
-  return NILP (val) ? make_fixnum (0) : val;
+  return ((IEEE_FLOATING_POINT ? NILP (val) : !NUMBERP (val))
+	  ? make_fixnum (0) : val);
 }
 \f
 enum arithop
diff --git a/src/lread.c b/src/lread.c
index 51d0d2a3c24..6792ef27206 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -75,6 +75,10 @@ #define file_tell ftell
 # ifndef INFINITY
 #  define INFINITY ((union ieee754_double) {.ieee = {.exponent = -1}}.d)
 # endif
+#else
+# ifndef INFINITY
+#  define INFINITY HUGE_VAL
+# endif
 #endif
 
 /* The objects or placeholders read with the #n=object form.
@@ -4477,10 +4481,17 @@ substitute_in_interval (INTERVAL interval, void *arg)
 }
 
 \f
+#if !IEEE_FLOATING_POINT
+/* Strings that stand in for +NaN, -NaN, respectively.  */
+static Lisp_Object not_a_number[2];
+#endif
+
 /* Convert the initial prefix of STRING to a number, assuming base BASE.
    If the prefix has floating point syntax and BASE is 10, return a
    nearest float; otherwise, if the prefix has integer syntax, return
-   the integer; otherwise, return nil.  If PLEN, set *PLEN to the
+   the integer; otherwise, return nil.  (On antique platforms that lack
+   support for NaNs, if the prefix has NaN syntax return a Lisp object that
+   will provoke an error if used as a number.)  If PLEN, set *PLEN to the
    length of the numeric prefix if there is one, otherwise *PLEN is
    unspecified.  */
 
@@ -4545,7 +4556,6 @@ string_to_number (char const *string, int base, ptrdiff_t *plen)
 		cp++;
 	      while ('0' <= *cp && *cp <= '9');
 	    }
-#if IEEE_FLOATING_POINT
 	  else if (cp[-1] == '+'
 		   && cp[0] == 'I' && cp[1] == 'N' && cp[2] == 'F')
 	    {
@@ -4558,12 +4568,17 @@ string_to_number (char const *string, int base, ptrdiff_t *plen)
 	    {
 	      state |= E_EXP;
 	      cp += 3;
+#if IEEE_FLOATING_POINT
 	      union ieee754_double u
 		= { .ieee_nan = { .exponent = 0x7ff, .quiet_nan = 1,
 				  .mantissa0 = n >> 31 >> 1, .mantissa1 = n }};
 	      value = u.d;
-	    }
+#else
+	      if (plen)
+		*plen = cp - string;
+	      return not_a_number[negative];
 #endif
+	    }
 	  else
 	    cp = ecp;
 	}
@@ -5707,6 +5722,14 @@ syms_of_lread (void)
   DEFSYM (Qcomma, ",");
   DEFSYM (Qcomma_at, ",@");
 
+#if !IEEE_FLOATING_POINT
+  for (int negative = 0; negative < 2; negative++)
+    {
+      not_a_number[negative] = build_pure_c_string (&"-0.0e+NaN"[!negative]);
+      staticpro (&not_a_number[negative]);
+    }
+#endif
+
   DEFSYM (Qinhibit_file_name_operation, "inhibit-file-name-operation");
   DEFSYM (Qascii_character, "ascii-character");
   DEFSYM (Qfunction, "function");
diff --git a/src/process.c b/src/process.c
index 67d1d3e425f..2d6e08f16b5 100644
--- a/src/process.c
+++ b/src/process.c
@@ -7130,7 +7130,8 @@ DEFUN ("internal-default-signal-process",
 	{
 	  ptrdiff_t len;
 	  tem = string_to_number (SSDATA (process), 10, &len);
-	  if (NILP (tem) || len != SBYTES (process))
+	  if ((IEEE_FLOATING_POINT ? NILP (tem) : !NUMBERP (tem))
+	      || len != SBYTES (process))
 	    return Qnil;
 	}
       process = tem;
-- 
2.39.2


  reply	other threads:[~2023-07-13 22:07 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-23 11:46 Disambiguate modeline character for UTF-8? Ulrich Mueller
2020-08-23 15:27 ` Stefan Monnier
2020-08-23 16:07   ` Eli Zaretskii
2020-08-23 18:24     ` Paul Eggert
2020-08-23 18:53       ` Ulrich Mueller
2020-08-23 18:56         ` Eli Zaretskii
2020-08-23 18:57         ` Eli Zaretskii
2020-08-23 19:13           ` Ulrich Mueller
2020-08-23 19:42             ` Eli Zaretskii
2020-08-23 21:23               ` Stefan Monnier
2020-08-24  7:06                 ` Ulrich Mueller
2020-08-24 14:30                   ` Yuri Khan
2020-08-29 11:17                     ` Ulrich Mueller
2020-08-24 14:36                   ` Drew Adams
2020-08-24 15:23                     ` Ulrich Mueller
2020-08-24 16:43                       ` Stefan Monnier
2023-07-05 10:08                       ` Ulrich Mueller
2023-07-05 11:41                         ` Eli Zaretskii
2023-07-05 13:04                           ` Ulrich Mueller
2023-07-05 13:44                             ` Eli Zaretskii
2023-07-05 21:50                               ` Ulrich Mueller
2023-07-05 22:11                                 ` Paul Eggert
2023-07-06  8:51                                   ` Ulrich Mueller
2023-07-06  5:33                                 ` Eli Zaretskii
2023-07-06  8:47                                   ` Ulrich Mueller
2023-07-06  9:20                                     ` Eli Zaretskii
2023-07-06  9:46                                       ` Ulrich Mueller
2023-07-06 12:34                                         ` Po Lu
2023-07-06 12:32                                     ` Po Lu
2023-07-06 12:31                                 ` Po Lu
2023-07-06 13:02                                   ` Andreas Schwab
2023-07-06 13:08                                   ` Ulrich Mueller
2023-07-06 17:37                                     ` Paul Eggert
2023-07-06 18:13                                       ` Eli Zaretskii
2023-07-06 18:44                                       ` Ulrich Müller
2023-07-06 19:01                                         ` Eli Zaretskii
2023-07-06 19:31                                           ` Ulrich Mueller
2023-07-07  5:18                                             ` Eli Zaretskii
2023-07-07  5:48                                               ` Ulrich Müller
2023-07-07  6:16                                                 ` Po Lu
2023-07-07  6:41                                                   ` Ulrich Mueller
2023-07-07  7:38                                                     ` Po Lu
2023-07-07  9:44                                                       ` Ulrich Mueller
2023-07-07 10:21                                                         ` Eli Zaretskii
2023-07-07 10:42                                                           ` Ulrich Mueller
2023-07-07 12:04                                                             ` Po Lu
2023-07-07 13:01                                                               ` Ulrich Mueller
2023-07-07 13:38                                                                 ` Po Lu
2023-07-07 12:01                                                         ` Po Lu
2023-07-07 12:38                                                           ` Andreas Schwab
2023-07-07 13:37                                                             ` Po Lu
2023-07-07 13:45                                                               ` Andreas Schwab
2023-07-07 12:58                                                           ` Eli Zaretskii
2023-07-08  8:49                                                 ` Eli Zaretskii
2023-07-08 15:27                                                   ` Basil Contovounesios
2023-07-08 15:38                                                     ` Eli Zaretskii
2023-07-08 16:21                                                       ` Basil Contovounesios
2023-07-08 16:33                                                         ` Eli Zaretskii
2023-07-08 16:57                                                           ` Basil Contovounesios
2023-07-08 18:21                                                         ` Ulrich Mueller
2023-07-08 21:31                                                           ` Basil Contovounesios
2023-07-09  9:22                                                       ` Lisp reader syntax and bootstrap (was: Re: Disambiguate modeline character for UTF-8?) Ulrich Mueller
2023-07-09  9:57                                                         ` Lisp reader syntax and bootstrap Po Lu
2023-07-13  2:04                                                           ` Richard Stallman
2023-07-13  4:27                                                             ` Po Lu
2023-07-13 22:07                                                               ` Paul Eggert [this message]
2023-07-14  5:05                                                                 ` Ulrich Mueller
2023-07-14  6:57                                                                   ` Paul Eggert
2023-07-15  2:10                                                                 ` Richard Stallman
2023-07-15  2:38                                                                   ` Po Lu
2023-07-15  5:18                                                                     ` Philip Kaludercic
2023-07-15  5:50                                                                       ` Po Lu
2023-07-15 15:22                                                                   ` Paul Eggert
2023-07-17  2:22                                                                     ` Richard Stallman
2023-07-17  5:26                                                                       ` Paul Eggert
2023-07-17  2:32                                                                     ` Po Lu
2023-07-16  2:19                                                               ` Richard Stallman
2023-07-09 11:35                                                         ` Lisp reader syntax and bootstrap (was: Re: Disambiguate modeline character for UTF-8?) Eli Zaretskii
2023-07-07  0:19                                     ` Disambiguate modeline character for UTF-8? Po Lu
2023-07-06 12:27                             ` Po Lu
2023-07-07  7:09                               ` UTF-32 (was: Re: Disambiguate modeline character for UTF-8?) Ulrich Mueller
2023-07-07  7:34                                 ` Eli Zaretskii
2023-07-07  8:20                                   ` UTF-32 Ulrich Mueller
2023-07-07 10:16                                     ` UTF-32 Eli Zaretskii
2023-07-07 10:34                                       ` UTF-32 Ulrich Mueller
2023-07-07 12:49                                         ` UTF-32 Eli Zaretskii
2023-07-07 13:24                                           ` UTF-32 Andreas Schwab
2023-07-07 13:36                                           ` UTF-32 Ulrich Mueller
2023-07-07 14:06                                             ` UTF-32 Eli Zaretskii
2023-07-05 12:49                         ` Disambiguate modeline character for UTF-8? Stefan Monnier
2023-07-05 13:38                           ` Eli Zaretskii
2023-07-06 19:07                           ` Filipp Gunbin
2020-08-23 19:47             ` Stefan Kangas
2020-08-24 18:35     ` Juri Linkov
2020-08-24 18:55       ` Eli Zaretskii
2020-08-25 18:59         ` Juri Linkov
2020-08-25 19:26           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5a110245-9b1c-be43-ca6e-2d37d3cac077@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=contovob@tcd.ie \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=luangruo@yahoo.com \
    --cc=rms@gnu.org \
    --cc=ulm@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).