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

[Walter Bright]

On 7/27/2024 2:30 AM, Richard (Rikki) Andrew Cattermole wrote:
> There are two solutions for a native language that isn't just ignoring it like 
> we do today. Check it at CT and warn/error if you do not handle null, or inject 
> read barriers like we do for bounds checks to cause the runtime exception.

How is `assert(p != null)` better?


> Note: this is solved in C/C++ world. They have such analysis in their compilers: 
> analyzer-null-dereference
> 
> https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Static-Analyzer-Options.html

-Wanalyzer-possible-null-argument

That's not solving it.

Many simple cases can indeed be found by DFA. But not all. There's also a lot of 
DFA trying to eliminate array bounds errors, but such errors remain the #1 
security problem with C and C++.

D does insert checks for array bounds overflow, because the hardware is of no help.


> It only takes one major outage where a business loses money before they consider 
> dumping a D companies solution. No client wants to hear: "We did this in a known 
> unsafe language for this particular error, when a more main stream language has 
> solutions to it and D doesn't."

How is this different from `assert(p != null)` ?