[RFC] Throwing an exception with null pointers (page 3)

On 15/04/2025 9:28 AM, Richard (Rikki) Andrew Cattermole wrote: > On 15/04/2025 8:53 AM, Derek Fawcus wrote: >> In trying to handle and recover from such things, you're up against a variant of Gödel's incompleteness theorem, and anyone offering a language which "solves" that is IMHO selling snake oil. > > In my original post I proposed a three tier solution. > > The read barriers are secondary to the language guarantees via type state analysis. > > You need them for when using a fast DFA engine, that doesn't do full control flow graph analysis and ignores a variable when it cannot analyze it. > > But if you are ok with having a bit of pain in terms of what can be modeled and can accept a bit of slowness, you won't need the read barriers. > > Unfortunately not everyone will accept the slower DFA therefore it can't be on by default. I know this as it copies a couple of the perceived negative traits of DIP1000. > > So yes we can solve this, but MT could still mess it up, hence the last option in the three solution; signals killing the process. I should mention, like the assert handler you would have the ability to configure the read barrier to do whatever you want at runtime. So if you prefer it to kill the process you can. As to what the default would be? Idk. The benefit of having it is that we can likely have a stack trace, where there might not be one otherwise.

On Monday, 14 April 2025 at 15:42:07 UTC, Derek Fawcus wrote:

On Monday, 14 April 2025 at 15:24:37 UTC, Richard (Rikki) Andrew Cattermole wrote:

It is important to note that a task isn't always a process. But once an event like null dereference occurs that task must die.

It is not the dereference which is the issue, that is the downstream symptom of an earlier problem. If that reference is never supposed to be null, then the program is already in a non deterministic even without the crash.

This is the exact problem. The solution proposed here just doesn't understand what the actual problem is. Null dereferences, and index out-of-bounds are programming errors. You need to fix them in the program, not recover and hope for the best.

Trying to recover is the equivalent of a compiler resolving a syntax ambiguity with a random number generator.

Null dereference?

Is it because I trusted a user value? => validate user input, rebuild, redeploy
Is it because I forgot to initialize something? => initialize it, rebuild, redeploy
Is it because I forgot to validate something? => do the validation properly, fix whatever it was sending in invalid data, rebuild, redeploy
Is it something else? => thank you program, for crashing instead of corrupting everything. Now, time to find the memory corruption somewhere.

Similar flow chart for out-of-bounds errors.

-Steve

22 hours ago

Re: [RFC] Throwing an exception with null pointers

Posted by Paolo Invernizzi
in reply to Alexandru Ermicioi

Permalink

Paolo Invernizzi

Posted in reply to Alexandru Ermicioi

Permalink

On Tuesday, 15 April 2025 at 07:23:14 UTC, Alexandru Ermicioi wrote:

On Tuesday, 15 April 2025 at 02:48:42 UTC, Steven Schveighoffer wrote:

On Monday, 14 April 2025 at 15:42:07 UTC, Derek Fawcus wrote:

On Monday, 14 April 2025 at 15:24:37 UTC, Richard (Rikki) Andrew Cattermole wrote:

It is important to note that a task isn't always a process. But once an event like null dereference occurs that task must die.

This simply is not manageable. Sometimes it is better to have semi operating systems rather ones that don't work at all because a minor thing in a tertiary module causes npe, while a fix is in progress.

Au contraire!

That's exactly why today we have:

kernels (or microkernels!)
processes living in userland
threads living in processes
coroutine (or similar stuff, whatever variant and name they take) living on thread
and least but not last VM, plenty of them.

I don't see a real use case for trying to recover a process from UB at all: go down the list and choose another layer.

Forums