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