Why were uninitialized floating-point variables changed to quiet NaN's in v2.087?

Richard (Rikki) Andrew Cattermole richard at cattermole.co.nz
Wed Jul 1 11:48:32 UTC 2026


On 01/07/2026 9:12 PM, FinalEvilution wrote:
> I was looking at the docs for std.math.hardware's [FloatingPointControl] 
> (https://dlang.org/phobos/std_math_hardware.html#.FloatingPointControl) 
> and i found the following lines
> and example interesting.
> 
>> "Note in particular that if invalidException is enabled, a hardware 
>> trap will be generated whenever an
> uninitialized floating-point variable is used."

The word "uninitialized" is wrongly used here.

An uninitialized variable may or may not contain a valid float value in it.

https://github.com/dlang/phobos/issues/11050

> ```
> {
>      FloatingPointControl fpctrl;
> 
>      // Enable hardware exceptions for division by zero, overflow to 
> infinity,
>      // invalid operations, and uninitialized floating-point variables.
> fpctrl.enableExceptions(FloatingPointControl.severeExceptions);
> 
>      // This will generate a hardware exception, if x is a
>      // default-initialized floating point variable:
>      real x; // Add `= 0` or even `= real.nan` to not throw the exception.
>      real y = x * 3.0;
> 
>      // The exception is only thrown for default-uninitialized NaN-s.
>      // NaN-s with other payload are valid:
>      real z = y * real.nan; // ok
> 
>      // The set hardware exceptions and rounding modes will be disabled 
> when
>      // leaving this scope.
> }
> ```
> 
> This seems nice. Turn on fp exceptions in your main for debug builds and 
> if it crashes use gdb
> to get the stack trace.
> 
> But the example doesn't work.
> 
> Looking at the [dmd Change Log](https://dlang.org/ 
> changelog/2.087.0.html#nan) uninitialized float's were changed from
> signaling NaN's to quiet NaN's in v2.087.0
> I looked at the [issue](https://bugzilla-archive.dlang.org/bugs/19905/) 
> and it's [see also](https://github.com/dlang/dmd/ 
> pull/7568#discussion_r159847869) but i don't understand what the harm 
> would be
> even if it's not 100% reliable.
> 
> Thanks.


```d
float f;

assert(f is float.init);
```

That will fail.

A signally NaN is a different value from a Quiet NaN and is expression 
is a bit wise compare.



More information about the Digitalmars-d-learn mailing list