[Not really OT] Crowdstrike Analysis: It was a NULL pointer from the memory unsafe C++ language.

[Walter Bright]

On 7/27/2024 12:00 PM, Richard (Rikki) Andrew Cattermole wrote:
> 1. You made the decision. You had to consider what would happen in this 
> situation. The question was asked, what happens should this be null? If you want 
> to assert that's fine. What is not fine is making an assumption and never state 
> it, never have it proven to be true.

?? Dereferencing a null pointer is always a bug, whether you decided to check 
for it or not.


> 2. It throws an exception (in D), which can be caught safely. It is only when 
> exception chaining occurs that the state may not have been cleaned up correctly.

Exceptions in D are the same as the ones used for seg faults (except for on 
Win64, where I couldn't figure out how the system exceptions worked).


> An even better solution to using an assert, is to use an if statement instead.
> 
> ```d
> if (int* ptr = var.field) {
>      // success
> } else {
>      // fail, you can gracefully degrade/log here
> }
> ```

The reason exceptions were invented was because such code for every pointer 
dereference made reasonable code look quite ugly.

Of course, you can still write such code if you like.


> Which means this:
> 
> ```d
> void func(int** ptr) {
>      assert(*ptr !is null);
> 
>      int i = **ptr; // ERROR: `**ptr` is in an unknown type state, it could be null
> }
> ```

Which means the language will require you to manually insert assert()s everywhere.


> For this reason, bounds checks do not need CT analysis.

Whether it is needed or not, the compiler can't do it.

> They do not have to bring down an application if caught.

Array overflows are fatal programming bugs.

A huge discussion about this raged in the n.g. many years ago. There was a camp 
that maintained that assert failures should be recoverable to the point that the 
program could continue.

The other camp maintained that when a program enters a state unanticipated by 
the programmer, then the program is not recoverable, because one no longer has 
any idea what will happen. The only path forward is to stop the program, 
gracefully or not.

Obviously, I'm in the latter camp. Obviously, one can write programs in the 
first camp (D lets you do whatever you want) but I cannot endorse it.


> On the other hand, null dereference requires signal handling to catch. If you 
> don't own thread and process you cannot use that to throw an exception. For this 
> reason it's not comparable and requires CT analysis to prevent bringing down the 
> process.

Whoever catches the signal will then stop the buggy, broken program from doing 
more damage. It's kinda the point of a computer with memory protection.


> On the other hand, if you were to propose read barriers that throw exceptions 
> for null dereference, I would agree to the statement that they are comparable.

That'll turn D into a very poorly performing language. Besides, throwing an 
exception is just what sig faults are. It's the same mechanism.


> Owner: Why did you use D! If you just used <insert mainstream application VM 
> language> we wouldn't have lost millions of dollars!!!

D is often unfairly accused of flaws.