[OT] OT: Null checks.

[Timon Gehr]

On 5/6/25 10:03, Walter Bright wrote:
> On 5/5/2025 11:30 PM, Max Samukha wrote:
>> Why would you assume that the code that doesn't rely on the GC is in a 
>> working state?
> 
> 
> You're right, there's no guarantee whatsoever that *any* of the code or 
> data is in a valid state.
> 
> But it's much less code, so correspondingly much less likely to have 
> been corrupted.
> 
> I prefer the "Go Directly To Jail, Do Not Pass Go, Do Not Collect $200" 
> method of dealing with crashed programs, hence my preference for 
> executing an invalid instruction. That comes from my experience with 
> avionics in aircraft, where when an invalid state is detected the faulty 
> box is immediately electrically isolated from the rest of the airplane, 
> and the backup is engaged.
> ...

This only works because the plane keeps its own state independent of the 
electronics.

> But, of course if you want logging, you'll have to risk it.
> 
> I would not enable such logging in any critical software, but it seems I 
> am the only such person.

At some point you'll just have to accept that most use cases are not 
like this. Then you will maybe also figure out that it is not about what 
kind of person you are, but about what kind of external factors are 
relevant to your work. (Hint: I am not currently writing software for 
avionics.)

And BTW, it appears an ESA mars mission failed partly because an 
acceleration sensor actively refused to operate for an extended amount 
of time after acceleration went out of the range it was rated for for a 
small amount of time. It did so by sticking to one of the ends of the 
rated range, making the probe compute that it was underground.

This demonstrates that your tools thinking they know better than you how 
to react to an error condition is also fatal in "critical" applications.