[OT] OT: Null checks.

[Richard (Rikki) Andrew Cattermole]

On 07/05/2025 12:04 PM, Walter Bright wrote:
> On 5/6/2025 1:53 AM, Richard (Rikki) Andrew Cattermole wrote:
>> This is why its so important to switch over to calling the global 
>> functions like assert handler does.
> 
> You cannot know if the global function is corrupted or not at that stage.
> 
> A bad actor can also hijack that global function to facilitate his 
> nefarious schemes.

Which is no different than a signal.

Or our existing assert handler.

>> People can configure it to do whatever they want, we don't have to 
>> have a default that is anything but instant crash.
> 
> It's not an instant crash. It generates an invalid instruction fault, 
> which then goes to a handler for it, and the default behavior of that 
> handler is to terminate the process.
> 
> I can tell I'm the oldest person here. I programmed for many years on a 
> machine that had no concept of a fault. When your program crashed, it 
> didn't stop. It kept running. It would execute data as instructions. 
> Invalid opcodes would execute random snippets of microcode. It would run 
> wild. Usually the only way to get control back is to do a cold boot. Now 
> *that* is a crash.
> 
> Having the program stop when it enters an invalid state is a good thing, 
> not a bad thing.
> 
> If you want to keep a program running on your customer's machine after 
> it crashes, that is entirely up to you. But I cannot recommend it.

Right, which is why everything I've said aligns with it defaulting to 
crashing out with a call to a function.

Even Windows supports logging in process on a crash. In practice this 
does work every day right now, running on your computer.