[RFC] Throwing an exception with null pointers

[Richard (Rikki) Andrew Cattermole]

On 16/04/2025 8:18 PM, Atila Neves wrote:
> On Monday, 14 April 2025 at 14:22:09 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> On 15/04/2025 1:51 AM, Atila Neves wrote:
>>> On Saturday, 12 April 2025 at 23:11:41 UTC, Richard (Rikki) Andrew 
>>> Cattermole wrote:
>>>> I've been looking once again at having an exception being thrown on 
>>>> null pointer dereferencing.
>>>> However the following can be extended to other hardware level 
>>>> exceptions.
>>>>
>>>> [...]
>>>
>>> I would like to know why one would want this.
>>
>> Imagine you have a web server that is handling 50k requests per second.
>>
>> It makes you $1 million dollars a day.
>>
>> In it, you accidentally have some bad business logic that results in a 
>> null dereference or indexing a slice out of bounds.
> 
> Possible mitigations:
> 
> * Use `sigaction` to catch `SIGSEGV` and throw an exception in the handler.

The only thing you can reliably do on segfault is to kill the process.

 From what I've read, they get awfully iffy, even with the workarounds.

And that's just for Posix, Windows is an entirely different kettle of 
fish and is designed around exception handling instead, which dmd 
doesn't support!

> * Use a nullable/option type.

While valid to box pointers, we would then need to disallow them in 
business logic functions.

Very invasive, not my preference.

> * Address sanitizer.

Slow at runtime, which kinda defeats the purpose.

> * Fuzzing the server (which one should do anyway).

Absolutely, but there is too much state to kinda guarantee that it 
covers everything. And very few people will get it to that level (after 
all, people need significant amount of training to do it successfully).

> How is out of bounds access related to null pointers throwing exceptions?

Out of bounds on a slice uses a read barrier to throw an exception.

A read barrier to prevent dereferencing a null pointer is exactly the 
same concept.

One is 0 or 1.

Second is 0 or N.

>> How likely are you to keep using D, or willing to talk about using D 
>> positively afterwards?
> 
> People write servers in C and C++ too

Yes they do, just like they do in D.

But they have something we do not have, a ton of static analysis.

Check, select professional developers: 
https://survey.stackoverflow.co/2024/technology#most-popular-technologies

C#, Java, Python, and JavaScript all out rank C and C++.

I'm not going to say they each have a good solution to the problem, but 
they each have a solution that isn't just kill the process.

The end of this foray into read barriers may be the conclusion that we 
cannot use them for this. What worries me is that I don't have the 
evidence to show that it won't work, and dismissing it without evidence 
does mean that we'll be forced to recommend full CFG DFA which is slow.

If it can work, using the read barriers to fill in the gap of what a 
faster DFA can offer would be a much better user experience. At least as 
a default.