Bug 5687 – std.string.format() error with "%a"

Status
RESOLVED
Resolution
DUPLICATE
Severity
normal
Priority
P2
Component
phobos
Product
D
Version
D2
Platform
Other
OS
Linux
Creation time
2011-03-02T23:23:00Z
Last change time
2012-04-01T15:04:28Z
Assigned to
nobody
Creator
bugzilla

Comments

Comment #0 by bugzilla — 2011-03-02T23:23:44Z
Magnus Lie Hetland wrote in D.learn: I just noticed that writefln("%a", 1.2) writes 0x1.3333333333333p+0, while writeln(format("%a", 1.2)) (that is, with std.string.format) writes 0x9.9999999999998p-3 ... wouldn't it be nice to be consistent here? (The former is what printf in gcc gives.)
Comment #1 by bugzilla — 2011-03-03T00:27:42Z
I've found the cause for this: 1.2 is a double, and should be formatted as such, but it is converted to a real internally in std.format.doFormat(). I think the right way to go is to rewrite std.string.format() in terms of std.format.formattedWrite() instead of std.format.doFormat().
Comment #2 by clugdbug — 2011-03-03T01:12:37Z
(In reply to comment #1) > I've found the cause for this: 1.2 is a double, and should be formatted as > such, but it is converted to a real internally in std.format.doFormat(). I don't think that's the reason. On Windows, the %A format always begins with 0x1. (except of course for 0, NaN, inf). You will never, under any circumstances, see something beginning with 0x9. Is it actually true that %A on Linux for doubles always begins with 0x1. ? If so, then it's a Linux %A bug for reals. In fact, converting from double to real should NEVER change the %a result. > I think the right way to go is to rewrite std.string.format() in terms of > std.format.formattedWrite() instead of std.format.doFormat().
Comment #3 by clugdbug — 2011-03-03T01:17:33Z
On Windows: import std.stdio; import std.string; void main() { writefln("%a", 1.2); writeln(format("%a", 1.2)); } ------- 0x1.3333333333333p+0 0x1.3333333333333p+0 ------- This bug is Linux-only.
Comment #4 by bugzilla — 2011-03-03T01:57:22Z
(In reply to comment #2) > Is it actually true that %A on Linux for doubles always begins with 0x1. ? Having tested with a large number of random doubles, that certainly seems to be the case. > If so, then it's a Linux %A bug for reals. Wow, you'd think someone would have discovered this before. > In fact, converting from double to real should NEVER change the %a result. Thinking some more about it, that makes sense.
Comment #5 by bugzilla — 2011-03-03T11:55:36Z
%a and %A formatting is done in Phobos using snprintf, which (sadly) produces different results on Windows than Linux. In order to properly fix this, we just need to write our own %a formatter.
Comment #6 by smjg — 2012-04-01T15:04:28Z
*** This issue has been marked as a duplicate of issue 4532 ***