Movement against float.init being nan

[Steven Schveighoffer]

On 8/25/22 9:01 PM, Walter Bright wrote:
> On 8/25/2022 10:38 AM, Steven Schveighoffer wrote:
>> 0 is no better here *but also no worse*.
> 
> 0 is equal or worse than NaN. It is true that sometimes 0 is equal. But 
> it is *never* better.

I fully don't ever expect any changes to come from this discussion. But 
just to continue the point here, yes, it's slightly better in *some 
cases*. The question to answer is *how many cases*, and is the pain 
caused by having to go correct problems that should never have existed 
in the first place worth fixing those few cases where it actually helps.

It's a matter of tradeoffs. There is no clear winner or loser, both have 
benefits and both have drawbacks. I've never encountered the benefits of 
NaN, so I'm biased towards initializing with 0.

> BTW, hex data doesn't have a NaN value. But a popular thing we'd do is 
> initialize it to:
> 
>    0xDEADBEEF
> 
> which is pretty unlikely to occur in the wild. So when dumping hex data, 
> and DEADBEEF is in there, you're very likely looking at uninitialized 
> data getting into the output.

That's great. Now how do you find out where the problem starts? What if 
DEADBEEF is in your dump, but it's just memory that isn't being used 
yet? Is it still a problem?

Note that this solves a mostly different problem -- using dangling 
pointers. This isn't about initialization.

-Steve