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

Tommi tommitissari at hotmail.com
Thu Apr 10 13:03:34 PDT 2014


On Thursday, 10 April 2014 at 19:48:16 UTC, Steven Schveighoffer 
wrote:
> On Thu, 10 Apr 2014 15:38:37 -0400, Tommi 
> <tommitissari at hotmail.com> wrote:
>
>> On Thursday, 10 April 2014 at 18:13:30 UTC, Steven 
>> Schveighoffer wrote:
>>> As a general rule, first profile, then optimize.
>>
>> Exactly. I profile the difference between running with and 
>> without bounds checking. If the difference is deemed 
>> negligible for our purposes, we don't spend time and money in 
>> carefully optimizing away bound checks that are analyzed to be 
>> reasonably safe to remove. You need the compiler flag to 
>> potentially save you all the trouble.
>
> This is a weak argument. If you need to optimize, do it. Bounds 
> checking is one of a thousand different possible explanations 
> for slow code. You have to weigh that remote possibility with 
> the threat of accidentally/inadvertently neutering @safe.
>
> You also exaggerate the cost of changing a few @safe to 
> @trusted. The cost of adding the -noboundscheck flag to the 
> build system in the right places may be just as significant.
>
> -Steve

Okay, I give up. You win this debate. Let's prevent D programmers 
from removing bounds checks from their programs with a compiler 
flag.


More information about the Digitalmars-d mailing list