Typical security issues in C++: why the GC isn't your enemy

[Siarhei Siamashka]

On Monday, 12 December 2022 at 23:48:58 UTC, areYouSureAboutThat 
wrote:
> So how about a compile time, commandline switch, that (warns or 
> fails) when @safe code is calling @trusted code?
>
> Basically, I'm, saying to the compiler -> "if it's not @safe, I 
> do not 'trust' it."

Then you will have this warning in pretty much every application. 
Because any @safe code eventually ends up doing OS kernel API 
calls to show stuff on your screen or save it to a hard drive. 
The bridge from @safe to @system has to be crossed somewhere and 
the code annotated as @trusted works as such bridge.

If your OS kernel is buggy, then it compromises the safety of 
your program and you can't do anything about this (other than 
patching up your OS kernel). If your @trusted function is buggy, 
then it compromises the safety of your program and you can't do 
anything about this (other than fixing bugs in the @trusted 
code). Of course, assuming that it was actually necessary to 
annotate the function as @trusted in the first place and it could 
not be @safe for a very good reason.

I don't see any problem with this model. It takes a deliberate 
effort to annotate a function as @trusted. You are not getting 
this attribute by default or via 
https://dlang.org/spec/function.html#function-attribute-inference