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

[Siarhei Siamashka]

On Monday, 12 December 2022 at 11:21:29 UTC, Basile B. wrote:
>> @trusted foo()
>> {
>>     int[5] array = [0, 1, 2, 3, 4];
>>
>>     for (size_t i = 0; i < array.length + 1; i++)
>>         writeln("Element ", i, " = ", array[i]);
>> }
>
> You're supposed to catch this bug during development and with 
> your tests

The amount of @trusted and @system code is supposed to be 
relatively small in any application (this is possible thanks to 
the Pareto principle), so it can be reviewed with extra scrutiny 
and carefully tested. And this code is the primary suspect when 
troubleshooting in case of troubles.

Testing and reviewing efforts can be allocated more efficiently 
when @safe and @trusted/@system code is segregated.

> but here the real problem is "-release" (that problem's been 
> mentioned earlier).

The real problem is not "-release". But the fact that way too 
much code gets annotated as @system for no reason. And for 
beginners even effectively without their intention/consent.

> That switch is not well designed. Bound checks could have their 
> own front-end optimizations so we could have
>
>     -boundscheck={on|optimized|off}

Such switch already exists. And I'm using it during development 
for very narrow specific purposes:

   1. To do a test build with "-boundscheck=off" and run 
benchmarks. If the performance difference is not measurable, then 
everything is fine. If there's some difference, then identify the 
part of code responsible for it and consider the risks/benefits 
of changing specifically this part to @trusted/@system.

   2. When debugging, "-boundscheck=on" for everything may assist 
in catching an unexpected bug in @trusted/@system code.

> instead of the current system, tied to the language safety 
> system.

Why instead? The two extreme options ("full checks everywhere" 
vs. "no checks at all") offered by the command line switches are 
not flexible and both have major disadvantages.