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

[Dukc]

Paolo Invernizzi kirjoitti 29.7.2024 klo 14.21:
> 
> The "review any @safe function ... like it was a @trusted function" is 
> an abomination, and totally dismiss the only reason to have @safe in the 
> language.
> 
> @safe: MECHANICALLY verified, it's safe, NO NEED to review.
> 

It is an abomination that's pretty much only the last resort, but saying 
it totally defeats the purpose of `@safe` is exaggregation.

Consider pre-DIP1000 semantics. You can easily corrupt memory from 
`@safe` code by slicing a static array on stack and returning that 
slice. Would you say that any code that isn't yet compatible with 
-dip1000 has no benefit from `@safe`?

Or consider immutable delegates. Due to language design flaws, an 
immutable delegate can have a mutable context. This breaks language 
assumptions about immutability in 100% `@safe` way. Would you say this 
defeats the purpose of `@safe` in the language?

Of course not. Those cases are incredibly annoying since they mean the 
mechanical check will fail sometimes, but you're still going to make far 
fewer memory corrupting mistakes in `@safe` code than `@system` code.

I don't see why creative use of `@trusted` is any different. Make no 
mistake, it's a game that can easily get out of hand and has to be 
highly discouraged, but it's not "do it once and you can never benefit 
from @safe".

You might object that yes, in principle you could open a hole or two and 
get away with it, but if you're doing it once you will do it again and 
again, until memory safety is a mere joke (like if you shoplift once or 
twice, you'll probably do it again and again until you get caught).

But I think it depends on why you'd do it. Done like Walter seems to be 
doing it, I agree. But there are situations where it's going to be much 
more defensible. Like the case I mentioned earlier - you have a function 
you thought was memory safe and later discover it's not, so you leave 
the `@trusted` label there for backwards compatibility (with appropriate 
warnings and a deprecation). If you do such a thing, I don't think it's 
going to make you lose your respect for memory safety in general.