Re: integer overflow handling for most-negative-fixnum

[Paul Eggert <eggert@cs.ucla.edu>]

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

Andy Moreton wrote:
> I see that you have pushed 57c4bc146b ("0x%x → %#x in elisp formats"),
> which will cause breakage as format is not well behaved:
> 
> ELISP> (format "%#x" 1)
> "0x1"
> ELISP> (format "%#x" 0)
> "0"                      ; Missing "0x" prefix (same misfeature as in C)
> 
> ELISP> (format "%#08x" 1)
> "0x000001"               ; Wrong number of digits printed
> ELISP> (format "%#08x" 0)
> "00000000"
> 
> For both of the above reasons, this change is not a good idea.

Thanks for mentioning the issue, as I had forgotten that (format "%#x" 0) yields 
"0" not "0x0". However, I don't see how 57c4bc146b breaks anything. The 
generated strings are used as nonces or arbitrary labels and as far as I can see 
nobody cares whether 0 is printed as "0" or as "0x0". (As none of the changes 
involve anything like "%#08x" I don't see the relevance of your second example.)

As I understand it 57c4bc146b is merely a nicety; it's certainly not needed for 
correctness now, and it's not needed for correctness even if we change how 
negative integers are formatted with %x. If I'm wrong and you still see 
correctness problems please feel free to revert it (though I'd like to know what 
the problems are...).

I now notice that this wrinkle about 'format' isn't documented despite being 
longstanding behavior that mirrors the C standard. It should be documented, so I 
installed the attached patch into master to fix the oversight.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-format-x-0-yields-0-not-0x0.patch --]
[-- Type: text/x-patch; name="0001-format-x-0-yields-0-not-0x0.patch", Size: 1836 bytes --]

From 90256285e107641b064d6ec51a9c5bb03c3eee6a Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 23 Jul 2018 10:23:35 -0700
Subject: [PATCH] (format "%#x" 0) yields "0", not "0x0"

* doc/lispref/strings.texi (Formatting Strings):
* src/editfns.c (Fformat): Document this.
---
 doc/lispref/strings.texi | 2 +-
 src/editfns.c            | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/lispref/strings.texi b/doc/lispref/strings.texi
index f68199e..2fff3c7 100644
--- a/doc/lispref/strings.texi
+++ b/doc/lispref/strings.texi
@@ -1025,7 +1025,7 @@ Formatting Strings
 
   The flag @samp{#} specifies an alternate form which depends on
 the format in use.  For @samp{%o}, it ensures that the result begins
-with a @samp{0}.  For @samp{%x} and @samp{%X}, it prefixes the result
+with a @samp{0}.  For @samp{%x} and @samp{%X}, it prefixes nonzero results
 with @samp{0x} or @samp{0X}.  For @samp{%e} and @samp{%f}, the
 @samp{#} flag means include a decimal point even if the precision is
 zero.  For @samp{%g}, it always includes a decimal point, and also
diff --git a/src/editfns.c b/src/editfns.c
index ccc0d27..09f836c 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -4202,7 +4202,7 @@ The - and 0 flags affect the width specifier, as described below.
 
 The # flag means to use an alternate display form for %o, %x, %X, %e,
 %f, and %g sequences: for %o, it ensures that the result begins with
-\"0\"; for %x and %X, it prefixes the result with \"0x\" or \"0X\";
+\"0\"; for %x and %X, it prefixes nonzero results with \"0x\" or \"0X\";
 for %e and %f, it causes a decimal point to be included even if the
 precision is zero; for %g, it causes a decimal point to be
 included even if the precision is zero, and also forces trailing
-- 
2.7.4