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.
