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

Sebastiaan Koppe mail at skoppe.eu
Sun Jul 28 22:19:38 UTC 2024


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.


More information about the Digitalmars-d mailing list