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.

Blog:
https://dlang.org/blog/2018/02/07/vanquish-forever-these-bugs-that-blasted-your-kingdom/

Reddit:
https://www.reddit.com/r/programming/comments/7vw0gj/vanquish_forever_these_bugs_that_blasted_your/

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.
>
> Blog:
> https://dlang.org/blog/2018/02/07/vanquish-forever-these-bugs-that-blasted-your-kingdom/


DynamicArray is actually laid out in length, pointer order. Thankfully only reaaally low-level code has to know that.

>
> Reddit:
> https://www.reddit.com/r/programming/comments/7vw0gj/vanquish_forever_these_bugs_that_blasted_your/

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.

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.

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)

On 2/7/2018 12:30 PM, Dmitry Olshansky wrote:
> While an enjoable read, I fear we are aiming too low.

I wished to show that array bounds overflow checking is not a tractable problem in C, i.e. you cannot make it go away by being a better programmer, and how BetterC solves this problem.


> Other languages like Rust or C# (or Java) have bounds check.
True, but I am trying to change the narrative about memory safe alternatives to C. So I plan a series of posts about how D addresses memory safety directed at C programmers.

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.

I think that at some point it should also be highlighted that many of the best part of Phobos will still work with BetterC. I just, using the excellent example of Cosinus as base, added this line to a code compiled with Emscripten, which so far requires BetterC:

foreach(num; iota(5, 15).map!(x => x*2)) printf("%d ", num);

And it worked just as in desktop, meaning that one can do pipeline programming in the internet using D! Or in any enviroment where D can compile to, D runtime or no.

This is probably no news to people who already know D compilers well, but for those less familiar with the internals it may be quite a welcome surprise.

On 11/02/2018 12:51 PM, Dukc 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.
> 
> I think that at some point it should also be highlighted that many of the best part of Phobos will still work with BetterC. I just, using the excellent example of Cosinus as base, added this line to a code compiled with Emscripten, which so far requires BetterC:
> 
> foreach(num; iota(5, 15).map!(x => x*2)) printf("%d ", num);
> 
> And it worked just as in desktop, meaning that one can do pipeline programming in the internet using D! Or in any enviroment where D can compile to, D runtime or no.
> 
> This is probably no news to people who already know D compilers well, but for those less familiar with the internals it may be quite a welcome surprise.

Out of interest will each! work here as well?

On Sunday, 11 February 2018 at 12:56:34 UTC, rikki cattermole wrote:
>> And it worked just as in desktop, meaning that one can do pipeline programming in the internet using D! Or in any enviroment where D can compile to, D runtime or no.

Well, I just remembered that the Emscripten compiler did warn about a unresolved symbol: _assert. I should have said that might prevent compilation somewhere but not on emcc as it just warns.

>
> Out of interest will each! work here as well?

in the form:

import std.algorithm, std.range;
iota(5, 15).map!(x => x*2).each!(num => printf("%d ", num));

...it does.

On 11/02/2018 1:13 PM, Dukc wrote:
> 
>>
>> Out of interest will each! work here as well?
> 
> in the form:
> 
> import std.algorithm, std.range;
> iota(5, 15).map!(x => x*2).each!(num => printf("%d ", num));
> 
> ...it does.

:)

On Wednesday, 7 February 2018 at 20:30:54 UTC, Dmitry Olshansky wrote:
> 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.
>

We all really need to get away from this idea that *we* should stop *others* from shooting themselves in the foot. People are free to do it, if they want. Who has the right to take that choice away from me?

So let's NOT be like those other languages that just want to control what you do.

-boundscheck=off

D rocks!