Vanquish Forever These Bugs That Blasted Your Kingdom

[H. S. Teoh]

On Wed, Feb 07, 2018 at 08:30:54PM +0000, Dmitry Olshansky via Digitalmars-d-announce wrote:
> On Wednesday, 7 February 2018 at 13:29:04 UTC, Mike Parker wrote:
> > Walter's got a new post up! It's the first in a new series on the
> > benefits of BetterC mode. In this one, he talks about solving the
> > fencepost problem (off-by-one errors) with D's arrays.
> 
> While an enjoable read, I fear we are aiming too low.
> 
> Other languages like Rust or C# (or Java) have bounds check. Plus we
> probably lose it in release mode, which is the mode where lurking bugs
> are discovered usually days after development ;) Some of these
> languages would prevent it on the VM level/compiler level, leaving no
> way to shoot yourself in the foot.

Arguably, in this day and age, bounds checks should never be elided even
in release builds, esp. if you're dealing with network-facing
interfaces.  There are just too many exploits caused by missing bounds
checks, that it's just not worth the minor performance gain. I'd rather
my server be a tiny bit slower, than for it to be vulnerable to yet
another buffer overflow attack.

In the few performance-critical inner loops where it might actually
matter, there are ways to work around it.


> If we have bounds checks by default it looks silly to have pointer
> arithmetic enabled by default. It’s like “we are safe from this
> problem, as long as you write code using this primitive not the other
> one”, which is basically safety by convention.

He did address this with @safe.  Of course, the ideal case is for @safe
to be default, but that boat has already long sailed.


T

-- 
People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)