In Phobos, there are quite a few unit tests (std.format, std.json, ...) which assume that the %e floating point format zero-pads the exponent to (at least) two digits.

However, the printf-family functions in the MSVC and MinGW runtimes pad the exponent to *three* digits. For example, 1.223e+24 is printed as "1.223e+024".

By extension, this also applies to the std.format (and thus std.stdio) floating point code, which relies on snprintf.

What is the correct fix here? Adjusting those unit tests? Doing something crazy along the lines of "if (result[$-4] == 'e' && result[$-3] == '0') { /+ trim zero +/ }"? (How) Is this handled on DMD/Win64?

The best way would probably be to just implement floating point printing in D as well, to isolate our code from such C runtime implementation differences.

David

On 2/20/13, David Nadlinger <see@klickverbot.at> wrote:
> In Phobos, there are quite a few unit tests (std.format,
> std.json, ...) which assume that the %e floating point format
> zero-pads the exponent to (at least) two digits.

I don't know about the exponent problem, but w.r.t. floating point there was a recent bug fixed where this source file:

auto x = 1.0;

Would be converted to this header file:

auto x = 1;

These are then different types. So I've changed how floating-point is written in DMD to always emit "1.0" rather than "1". This also improved diagnostics.

But I wanted to always print at most two digits in this case (e.g. 1.00, 2.00, etc) but couldn't find a good way to do it with sprintf, so currently for floating-point e.g. "1" it prints "1.00000" in diagnostics and header files, which is excessive.

Anyway I would definitely like to see floating-point printing synchronized across multiple compilers and also the D library, to be consistent everywhere.

On Wednesday, 20 February 2013 at 22:34:15 UTC, Andrej Mitrovic wrote:
> On 2/20/13, David Nadlinger <see@klickverbot.at> wrote:
>> In Phobos, there are quite a few unit tests (std.format,
>> std.json, ...) which assume that the %e floating point format
>> zero-pads the exponent to (at least) two digits.
>
> I don't know about the exponent problem, but w.r.t. floating point
> there was a recent bug fixed where this source file:
>
> auto x = 1.0;
>
> Would be converted to this header file:
>
> auto x = 1;
>
> These are then different types. So I've changed how floating-point is
> written in DMD to always emit "1.0" rather than "1". This also
> improved diagnostics.%
>
> But I wanted to always print at most two digits in this case (e.g.
> 1.00, 2.00, etc) but couldn't find a good way to do it with sprintf,
> so currently for floating-point e.g. "1" it prints "1.00000" in
> diagnostics and header files, which is excessive.
>
> Anyway I would definitely like to see floating-point printing
> synchronized across multiple compilers and also the D library, to be
> consistent everywhere.


Another related issue is the format of %a. On Windows it prints
0x1.444p+99
but on Linux the same number is
0x0.A22p+99
That's much easier to deal with, because it's trivial to print the %A format.
Correctly-rounded %e, %f is much more difficult, unfortunately (you need some
simple bigint arithmetic).