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

[Timon Gehr]

On 12/15/22 09:01, Dom DiSc wrote:
> 
> 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.

This is a fallacy. All it achieves is:

- Some incomplete @safe-ty checks in code that should _actually_ be 
`@system/@trusted` (this part can be useful, but OTOH you will have 
`@safe` annotations that are fundamentally a lie).

- Unknown scope of _actual_ `@trusted`, you will have to manually check 
_`@safe`_ code as well, and a priori you will have no idea how much of 
it you have to check (this part is terrible).

It certainly does not help you minimize the number of lines you have to 
check.