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

[Dom DiSc]

On Wednesday, 14 December 2022 at 11:45:02 UTC, Dukc wrote:
> ```D
> @safe void main() {
>     () @trusted { f(); }(); // ok!
> }
> ```
>
> The difference is that D lets you also write
>
> ```D
> @trusted void main() {
>     f(); // ok!
> }
> ```
>
> This is really just a nice shorthand for the `@safe` main with 
> `@trusted` lambda inside. It's also a better practice, since 
> `@trusted` in a function signature is easier to spot for a code 
> reviewer than the lambda inside the function.

I don't think so. A search for @trusted finds both.
But the lambda reduces the amount of @trusted code (e.g. all the 
rest in main() can be @safe, so you don't need to check it).
On the contrary: I would allow @trusted blocks (so that the ugly 
lambda construct wouldn't be necessary anymore) and forbid 
@trusted functions altogether - they are simply @system.

This allows to reduce the trusted parts step by step by declaring 
@system functions as @save and instead mark the few lines in them 
that do unsafe things as @trusted - until there are no @system 
functions anymore and the @trusted parts don't contain any calls 
(except for external calls to parts out of your control because 
they are from unsafe languages or the source is not available - 
which should be avoided, unless someone guarantees* them to be 
save).

Best practice should be to use @trusted around as few lines of 
code as possible (and of course avoid @system as far as possible).
This is because everything @trusted need to be checked manually 
and this is very time consuming.

*Meaning: Pays for any damage, if this fails.