Re: integer overflow handling for most-negative-fixnum

[Andy Moreton <andrewjmoreton@gmail.com>]

On Mon 23 Jul 2018, Paul Eggert wrote:

> 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.)

The breakage is that anything expected to line up nicely in columns is
broken when "0x%x" is replaced by "%#x" as any zero values are no longer
the same output width.

Also, if the width is specified as 8 I expect to see 8 digits of output,
not 6.

> 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.

Thanks for the doc fix. While I think this is a misfeature in C and in elisp,
it is decades too late to change the behaviour.

    AndyM