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

[Timon Gehr]

On 7/29/24 00:19, Sebastiaan Koppe wrote:
> On Sunday, 28 July 2024 at 18:21:41 UTC, Timon Gehr wrote:
>> ...
>>
>> The main reason why `@safe` is hard is that quite a few people, most 
>> importantly Walter, want it to be expressive. DIP1000 is already 
>> harder than `@safe` needs to be. The simplest possible definition of 
>> `@safe` is: just use the GC. This was Robert's point at last years 
>> DConf: "Why are you even taking references to stack memory in @safe?"
> 
> Let me answer that question. I believe it comes in three parts:
> 
> 1) Why references? To have distinct pieces of code refer to the same 
> object.
> 2) Why on the stack? To avoid heap allocations. Not only does it take 
> time to allocate (and deallocate), it can also trigger a garbage 
> collection and might kill any locality you are trying to achieve.
> 3) Why in @safe? To provide a safe interface instead of footguns.
> 
> @safe isn't a pledge to never write potentially unsafe code ever again 
> (e.g. just use the GC, don't do ref, etc.), instead it is to have the 
> compiler check your code for safety violations and to allow building a 
> safe interface around code the compiler can't check. (Note the second 
> part is an enabler for more of the first.)
> 
> Why anyone would want to have references to stack memory in @safe is 
> because it gives them an edge. They put in the hard work to provide a 
> @safe interface because it enables more safety check, and, not 
> unimportantly, they prefer that work over debugging memory issues.

I think this is a good answer. (But note that my point was just that 
@safe is not inherently very hard, it is as hard as you make it in the 
interest of expressiveness, performance, and crash safety.)