[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#31938: closed (regression in (format "%d" -0.0))
Date: Mon, 25 Jun 2018 19:39:02 +0000

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

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.

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

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]