[Not really OT] Crowdstrike Analysis: It was a NULL pointer from the memory unsafe C++ language.
Timon Gehr
timon.gehr at gmx.ch
Mon Jul 29 14:14:05 UTC 2024
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.)
More information about the Digitalmars-d
mailing list