Re: integer overflow handling for most-negative-fixnum

[Paul Eggert]

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.

0001-format-x-0-yields-0-not-0x0.patch
Description: Text Data