A serious security bug... caused by no bounds checking.

[Steven Schveighoffer]

On Fri, 11 Apr 2014 08:35:07 -0400, Daniel Murphy  
<yebbliesnospam at gmail.com> wrote:

> "Steven Schveighoffer"  wrote in message  
> news:op.xd3vzecweav7ka at stevens-macbook-pro.local...
>
>> No, the author of the @safe code expects bounds checking, it's part of  
>> the requirements. To compile his code with it off is like having  
>>   -compilergeneratedhash switch that overrides any toHash functions  
>> with a compiler generated one. You are changing the agreement between  
>> the compiler and the code. When I say @safe, I mean "I absolutely  
>> always want bounds checks."
>
> If you have code that would ever fail a bounds check, that is a program  
> error, similar to code that may fail an assertion.
>
> And like assertions, if you would rather the code was as fast as  
> possible instead of as safe as possible you can use a compiler switch to  
> disable bound checks.
>
> The usual switch to do stuff like this is '-release', but because @safe  
> functions should still have the 'no memory corruption' even in release  
> mode, disabling those bounds checks was moved into another compiler  
> switch.
>
>> If you want to eliminate bounds checks, use @trusted.
>
> No, @trusted means "don't check my code" while @safe + noboundschecks  
> means (mostly) "only check my code at compile-time".

Here is the horror scenario I envision:

1. Company has 100kLOC project, which is marked as @safe (I can dream,  
can't I?)
2. They find that performance is lacking, maybe compared to a competitor's  
C++ based code.
3. They try compiling with -noboundscheck, get a large performance boost.  
It really only makes a difference in one function (the inner loop one).
4. They pat themselves on the back, and release with the new flag,  
destroying all bounds checks, even bounds checks in library template code  
that they didn't write or scrutinize.
5. Buffer overflow attacks abound.
6. D @safe is labeled a "joke"

But there is a cost, even to labeling the "one inner" function @trusted.  
Perhaps that function is extremely long and complex. There should be a way  
to say, "I still want all the @safety checks, except for this one critical  
array access, I have manually guaranteed the bounds". We don't have  
anything like that. All other safety checks are really static, this is the  
only runtime penalty for safety.

The blunt flag approach is scary. @trusted is better, in that you can  
focus on one function at a time. But I think we need something more  
precise. Perhaps you should be able to have @trusted scopes, or @trusted  
expressions.

-Steve