Movement against float.init being nan

Timon Gehr timon.gehr at gmx.ch
Tue Aug 30 00:27:05 UTC 2022


On 25.08.22 18:56, Walter Bright wrote:
> On 8/25/2022 9:16 AM, IGotD- wrote:
>> Which is strange because HW wise it is trivial to check if the result 
>> is NaN. To check that NaN is not based on input is of course more 
>> complicated. Then again an x86 complicated in an unhealthy way.
>>
>> This kind of makes another motivation to let floats default to zero, 
>> if this is correct.
> 
> 
> There's nothing to be afraid of in getting a NaN in the output. One 
> should be glad, because then one *knows* there's a bug.
> 
> This thread reminds me of the threads about assert, and the contention 
> that the program should continue after a failed assert.
> ...

Clearly you should throw away your computer after a failed assert.

> 1. It is not better to pretend a program is working when it is not.
> 
> 2. It is not better for a language to guess at what the programmer must 
> have meant, even if the guess is correct 99% of the time.
> 
> 3. It is not better to never check the output of the program for 
> correctness.
> 
> D is a tool for helping the programmer create correct, robust, and 
> bug-free programs.

Which is why asserts can introduce new _undefined behavior_?


More information about the Digitalmars-d mailing list