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

[Daniel Murphy]

"Steven Schveighoffer"  wrote in message 
news:op.xd5lomc1eav7ka at stevens-macbook-pro.local...

> 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"

Trying to prevent developer stupidity is a lost cause.

Bounds checks are on by default.  They are even on when you ask for 
'fast-over-safe' aka -release.  They get turned off when you explicitly ask 
for it.

> 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.

Something like (() @trusted => arr.ptr[index]) should do the trick.

> 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.

@trusted delegates get you 99.99% of the way there.