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

[Basile B.]

On Monday, 12 December 2022 at 06:13:20 UTC, youSureAboutThat 
wrote:
> On Monday, 12 December 2022 at 05:06:06 UTC, youSureAboutThat 
> wrote:
>>
>
> just to clarify -> when @safe isn't safe:
>
>
> module test;
>
> import std.stdio;
>
> // so -boundscheck=off will always disable runtime boundscheck,
> // regardless of whether code is annotated as @safe, @system, 
> or @trusted.
>
> // -release will disable runtime boundscheck for code annotated 
> as @trusted and @system
> // however, code annotated with @safe will still have runtime 
> boundscheck enabled.
>
> // here is where it's a little tricky...
> // calling code annotated with @trusted from code annotated 
> with @safe (see below).
>
> @safe void main() { foo(); } // even though this is marked as 
> @safe
>                              // when you compile with -release
>                              // boundscheck is disabled for 
> foo()
>                              // since foo() is marked as 
> @trusted
>                              // and -release removes boundscheck
>                              // for @trusted and @system..(but 
> not @safe)
>
> @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 but here the real problem is "-release" (that 
problem's been mentioned earlier).

That switch is not well designed. Bound checks could have their 
own front-end optimizations so we could have

     -boundscheck={on|optimized|off}

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