[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