www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Vanquish Forever These Bugs That Blasted Your Kingdom

reply Mike Parker <aldacron gmail.com> writes:
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/
Feb 07 2018
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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/
Feb 07 2018
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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. 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.
Feb 07 2018
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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. 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)
Feb 07 2018
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.

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.
Feb 07 2018
prev sibling next sibling parent reply psychoticRabbit <meagain meagain.com> writes:
On Wednesday, 7 February 2018 at 20:30:54 UTC, Dmitry Olshansky 
wrote:

 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!
Feb 11 2018
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 11 February 2018 at 15:11:55 UTC, psychoticRabbit 
wrote:
 On Wednesday, 7 February 2018 at 20:30:54 UTC, Dmitry Olshansky 
 wrote:

 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!
That explains why there are so much SJW types in the Rust world :-)
Feb 11 2018
parent Chris <wendlec tcd.ie> writes:
On Sunday, 11 February 2018 at 15:15:45 UTC, Patrick Schluter 
wrote:

 That explains why there are so much SJW types in the Rust world 
 :-)
No, here's why: "Rust is a systems programming language[9] sponsored by Mozilla Research" "Mozilla" is the magic word ;) https://en.wikipedia.org/wiki/Rust_(programming_language)
Feb 12 2018
prev sibling next sibling parent reply Cym13 <cpicard openmailbox.org> writes:
On Sunday, 11 February 2018 at 15:11:55 UTC, psychoticRabbit 
wrote:
 On Wednesday, 7 February 2018 at 20:30:54 UTC, Dmitry Olshansky 
 wrote:

 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!
On the other hand, if my bank shoots itself in the foot it's with my money... We must definitely have ways to do it but it must be explicit and restricted to where it's useful. There is no need for -boundscheck=off in D. It is always possible to disable boundschecking locally, and that's a good thing.
Feb 11 2018
parent reply psychoticRabbit <meagain meagain.com> writes:
On Sunday, 11 February 2018 at 15:18:20 UTC, Cym13 wrote:
 On the other hand, if my bank shoots itself in the foot it's 
 with my money... We must definitely have ways to do it but it 
 must be explicit and restricted to where it's useful. There is 
 no need for -boundscheck=off in D. It is always possible to 
 disable boundschecking locally, and that's a good thing.
When was the last time a bank lost customers money due not checking bounds? It's far, far more likely you'll lose your money due to their dodgy lending practices (as many have already experienced).
Feb 11 2018
parent reply Cym13 <cpicard openmailbox.org> writes:
On Monday, 12 February 2018 at 04:30:38 UTC, psychoticRabbit 
wrote:
 On Sunday, 11 February 2018 at 15:18:20 UTC, Cym13 wrote:
 On the other hand, if my bank shoots itself in the foot it's 
 with my money... We must definitely have ways to do it but it 
 must be explicit and restricted to where it's useful. There is 
 no need for -boundscheck=off in D. It is always possible to 
 disable boundschecking locally, and that's a good thing.
When was the last time a bank lost customers money due not checking bounds? It's far, far more likely you'll lose your money due to their dodgy lending practices (as many have already experienced).
As someone who's job is to audit banking and governmental systems for security vulnerabilities, I can assure you it's a real issue. Not the most common one, okay, but that doesn't make it any less dangerous.
Feb 11 2018
parent psychoticRabbit <meagain meagain.com> writes:
On Monday, 12 February 2018 at 07:10:42 UTC, Cym13 wrote:
 As someone who's job is to audit banking and governmental 
 systems for security vulnerabilities, I can assure you it's a 
 real issue. Not the most common one, okay, but that doesn't 
 make it any less dangerous.
humans auditing the work of humans - what could be more dangerous than that ;-)
Feb 12 2018
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Sunday, 11 February 2018 at 15:11:55 UTC, psychoticRabbit 
wrote:
 On Wednesday, 7 February 2018 at 20:30:54 UTC, Dmitry Olshansky 
 wrote:

 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?
Your customers if you have any. Brcause they is inevitably you one day.
 So let's NOT be like those other languages that just want to 
 control what you do.
Then pick assembly of sorts. C ABI is a stright-jacket that ensures e.g. that your callstack is laid out correctly so that a ‘ret’ will bring you back to the call site not somewhere else. Do I need to mention libc’s machinations done “for compatibility”. Who the fuck were these guys to steal the pleasure of misaligned stacks and wrong push/pop order? Or register save missed? The reality is we are programming on top of increasingly complex run-times that solve low-level problems to certain extents. That includes C (even w/o libc) and pretty much any other high-level language.
 -boundscheck=off

 D rocks!
Feb 11 2018
parent psychoticRabbit <meagain meagain.com> writes:
On Monday, 12 February 2018 at 06:28:15 UTC, Dmitry Olshansky 
wrote:
 Then pick assembly of sorts.
 C ABI is a stright-jacket that ensures e.g. that your callstack 
 is laid out correctly so that a ‘ret’ will bring you back to 
 the call site not somewhere else. Do I need to mention libc’s 
 machinations done “for compatibility”.

 Who the fuck were these guys to steal the pleasure of 
 misaligned stacks and wrong push/pop order? Or register save 
 missed?

 The reality is we are programming on top of increasingly 
 complex run-times that solve low-level problems to certain 
 extents. That includes C (even w/o libc) and pretty much any 
 other high-level language.


 -boundscheck=off

 D rocks!
"D is in a conflicted position regarding the bounds checking conundrum. The language is trying to offer at the same time the safety and convenience of modern languages and the ultimate unmuffled performance sought by system-level programmers. The bounds checking issue implies a choice between the two, and D allows you to make that choice instead of making it for you." [ Andrei Alexandrescu - The D Programming Language, 2010] (again) -boundscheck=off D rocks!
Feb 12 2018
prev sibling parent reply Ali <fakeemail example.com> writes:
On Wednesday, 7 February 2018 at 20:30:54 UTC, Dmitry Olshansky 
wrote:
 On Wednesday, 7 February 2018 at 13:29:04 UTC, Mike Parker 
 wrote:
 While an enjoable read, I fear we are aiming too low.


Maybe I was missing the point, but isnt the objective or the feature of the betterC mode, is to integrate C code, in a D program seamlessly by allowing to import C headers into a D program And then from that point forward, use D features that improve on what C offers .. Again maybe I completely misunderstood the betterC mode but I thought that, that was it .. which justify the feature being called betterC, since this mode specifically target C And if it was, this is not really about how advanced a language feature are It is more how you can improve a C code based, by incrementally integrating D without loosing performance, or control
Feb 12 2018
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/12/2018 12:35 PM, Ali wrote:
 It is more how you can improve a C code based, by incrementally integrating D 
 without loosing performance, or control
Yes, with the focus on "incrementally".
Feb 12 2018
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
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.
Feb 11 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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?
Feb 11 2018
parent reply Dukc <ajieskola gmail.com> writes:
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.
Feb 11 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
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.
:)
Feb 11 2018
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Wednesday, 7 February 2018 at 13:29:04 UTC, Mike Parker wrote:
 Blog:
 https://dlang.org/blog/2018/02/07/vanquish-forever-these-bugs-that-blasted-your-kingdom/
Small mistake:
 Assertion failure: 'array overflow' on line 11 in file 'sum.d'
should be "line 10" there. P.S. There is an unanswered question in the comment section.
Feb 12 2018
parent Seb <seb wilzba.ch> writes:
On Monday, 12 February 2018 at 23:41:14 UTC, Bastiaan Veelo wrote:
 On Wednesday, 7 February 2018 at 13:29:04 UTC, Mike Parker 
 wrote:
 Blog:
 https://dlang.org/blog/2018/02/07/vanquish-forever-these-bugs-that-blasted-your-kingdom/
Small mistake:
 Assertion failure: 'array overflow' on line 11 in file 'sum.d'
should be "line 10" there. P.S. There is an unanswered question in the comment section.
Answered (the same question was also asked on reddit. O_O)
 Your comment is awaiting moderation.
Feb 12 2018