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)