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

Steven Schveighoffer schveiguy at yahoo.com
Fri Apr 11 06:44:11 PDT 2014


On Fri, 11 Apr 2014 09:35:12 -0400, Tommi <tommitissari at hotmail.com> wrote:

> On Friday, 11 April 2014 at 13:13:22 UTC, Steven Schveighoffer wrote:
>> 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"
>
> More likely:
> 6. This company's programming department is labeled a "joke".

Perhaps, but it doesn't change the idea that @safe code had memory bugs.  
What we are saying with @safe is that you CAN'T have memory bugs, no  
matter how incompetent your programmers are.

>> 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.
>
> We have array.ptr[idx]

Not allowed in @safe code.

-Steve


More information about the Digitalmars-d mailing list