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

[Paolo Invernizzi]

On Monday, 29 July 2024 at 09:04:36 UTC, Dukc wrote:
> Paolo Invernizzi kirjoitti 29.7.2024 klo 11.13:
>> 
>> There's no two semantic meaning of @trusted, there's only one: 
>> the interface MUST be safe.
>
> That's what the standard says. Therefore, I agree that's what 
> it means by default.
>
> On the other hand bit of technical safewashing may the best way 
> to go in exceptional cases. Say, maybe the function was earlier 
> thought as safe but later on proved to have an unsafe corner 
> case, and it was inpractical to remove `@trusted` right away 
> because the function is so widely used. I would not outright 
> ban a false `@trusted` in such cases, provided that it's 
> clearly documented as such.

Are you suggesting to advertise the library as memory safe, 
knowing it's not?
Do you have an idea of the legal consequences a company can have 
in this case?

What you are describing it's a bug, a memory safety bug that must 
be for sure disclosed to customers, but closed. And thinking 
about it, the best way is to have a separate attribute to mark it 
in the code, instead of @trusted.


> That is, if you're reading undocumented code and see a function 
> with `@trusted`, you can trust it's safe. So that we don't need 
> to separately document "safe interface" to the genuine 
> `@trusted` functions we write.

That's _exactly_ the contrary of @trusted philosophy, and 
semantic. It's non-sense.