Three floating point questions

[Don]

bearophile wrote:
> This program prints (dmd 2.048):
> 7ff4000000000000
> 7ffc000000000000
> 
> // program #1
> import std.stdio: writeln, writefln;
> import std.string: format;
> void main() {
>     string toHex(T)(T x) {
>         string result;
>         ubyte* ptr = cast(ubyte*)&x;
>         foreach (i; 0 .. T.sizeof)
>             result = format("%02x", ptr[i]) ~ result;
>         return result;
>     }
>     writeln(toHex(double.init));
>     writefln("%x", cast(ulong)double.init);
> }
> 
> Do you know what cast(ulong) is doing here?

Turning it from a signalling nan to a quiet nan.

> ---------------------------
> 
> This program prints (dmd 2.048)::
> -nan
> 
> // program #2
> import std.stdio: writeln;
> void main() {
>     writeln(0.0 / 0.0);
> }
> 
> Is it a bug of writeln?

You mean, because it's a negative nan?

> ---------------------------
> 
> Do you know why this isn't raising runtime errors?
> 
> // program #3
> import std.math: FloatingPointControl;
> import std.c.stdlib: atof;
> void main() {
>     double d3 = atof("3.0");
>     double x; // nan
>     FloatingPointControl fpc;
>     fpc.enableExceptions(FloatingPointControl.severeExceptions);
>     double r = x * d3;
> }

That's a known bug in the backend, which I still haven't fixed. The 
signalling nans get triggered in the 'double x; ' line.
This happens because there's a difference in the way AMD and Intel deal 
with signalling nans, which is completely unpublicised. So my initial 
testing was inadequate.