[debbugs-tracker] bug#31938: closed (regression in (format "%d" -0.0))

[GNU bug Tracking System]

Your message dated Mon, 25 Jun 2018 12:38:02 -0700
with message-id <address@hidden>
and subject line Re: bug#31938: followup
has caused the debbugs.gnu.org bug report #31938,
regarding regression in (format "%d" -0.0)
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
31938: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31938
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> regression in (format "%d" -0.0)
>
>
>
>
> Date: 
>
> Fri, 22 Jun 2018 20:01:59 +0200
>
>
>
>
> Severity: serious
>
> Emacs 24-26:
>
>     (format "%d" -0.0) => "0"
>
> Emacs 27:
>
>     (format "%d" -0.0) => "-0"
>
> I think this is a very important regression, because it happens in
> very low-level code and can lead to unpredictable results in certain
> special cases. Caught with real-world `datetime' package: on Emacs 27
> all its regression tests fail because of this change, on Emacs 24-26
> they pass.
>
> In the library, -0.0 comes from the fact that `mod' built-in can
> return it as a result (it is probably fine, because it is _equal_ to
> 0.0, so it is not negative, even if it looks like it).
>
> I.e. real code looks more like this:
>
>     (let ((x -2.0)) (format "%d" (mod x 2)))
>
> which gives "-0" and is a regression in Emacs 27.
>
>
>
> --- End Message ---

--- Begin Message --- Subject: Re: bug#31938: followup Date: Mon, 25 Jun 2018 12:38:02 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 06/23/2018 04:46 AM, Eli Zaretskii wrote:

From: Paul Pogonyshev <address@hidden>
Date: Sat, 23 Jun 2018 12:21:00 +0200

Another difference. In Emacs 24-26:

     (format "%d" 0.9) => "0"

In Emacs 27:

     (format "%d" 0.9) => "1"

This looks like the (unintended?) result of 80e145fc9.

I vaguely recall relying on the Elisp manual, which says that %d must be applied only to integers, and I guess I figured the semantics didn't matter so that the simplest implementation (thought that rounding and keeping -0) would satisfy the doc and anyway would be more helpful than truncating and discarding the sign of -0. But now that I reread the manual I see that it says %d must signal an error when given a float, which is obviously not the behavior, so the manual is wrong. And now that this issue has come up I notice that 80e145fc9 caused %d to behave inconsistently with %x; the latter truncates and converts -0 to 0 whereas the former rounds and keeps -0. This inconsistency is not good.

To try to improve this, I installed the attached into master to change 'format' to be more compatible with Emacs 26 etc. and am boldly closing the bug report.

0001-format-d-F-now-truncates-floating-F.patch
Description: Text Data

--- End Message ---