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

[Timon Gehr]

On 7/26/24 16:59, Guillaume Piolat wrote:
>>
> 
> Not really big on @safe (where is the RoI????

Well, I am perfectly fine with people just not using `@safe`. However, 
when I actually want some dependency to be `@safe` because it has to 
deal with potentially adversarial input, I'd prefer if the author 
actually took some care to make the interface solid.

> where are the products that beat the competition by being safe),

Then why would you even care to lie to prospective users? Just don't use 
`@safe` at that point.

> but when currently used @trusted has 2 different semantic meanings:
> 
> 1 - @trusted that means "I've audited that the @system function I call 
> are memoy-safe.

This is what it's being advertised as.

> do not grep this, there is nothing to see"

You can still grep to see if you agree with the assessment.

> 2 - @trusted that means "TODO, this is necessary because I've slapped 
> @safe on top and must go on with productive things. I'll get back later! 
> I should have marked this @system in the first place. I promise i'll get 
> back and fix it!!1"

What is even the point? If you think maintaining a memory-safe interface 
is a waste of time and a non-feature, something that nobody actually 
needs, don't even attempt to do it.

Either `@safe` is a feature we want in the language, then it should be 
solid, or we'd be better off just removing it. What I am not on board 
with is making `@safe` a priority while at the same time abandoning 
memory safety in `@safe` code. This makes no sense.