|
From: | Paul Eggert |
Subject: | Re: integer overflow handling for most-negative-fixnum |
Date: | Mon, 23 Jul 2018 10:30:15 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |