digitalmars.D.announce - Vanquish Forever These Bugs That Blasted Your Kingdom
- Mike Parker (7/7) Feb 07 2018 Walter's got a new post up! It's the first in a new series on the
- Dmitry Olshansky (3/11) Feb 07 2018 DynamicArray is actually laid out in length, pointer order.
- Dmitry Olshansky (11/15) Feb 07 2018 While an enjoable read, I fear we are aiming too low.
- H. S. Teoh (14/30) Feb 07 2018 Arguably, in this day and age, bounds checks should never be elided even
- Walter Bright (7/9) Feb 07 2018 I wished to show that array bounds overflow checking is not a tractable ...
- psychoticRabbit (10/16) Feb 11 2018 We all really need to get away from this idea that *we* should
- Patrick Schluter (4/21) Feb 11 2018 That explains why there are so much SJW types in the Rust world
- Chris (6/8) Feb 12 2018 No, here's why: "Rust is a systems programming language[9]
- Cym13 (7/24) Feb 11 2018 On the other hand, if my bank shoots itself in the foot it's with
- psychoticRabbit (5/10) Feb 11 2018 When was the last time a bank lost customers money due not
- Cym13 (6/17) Feb 11 2018 As someone who's job is to audit banking and governmental systems
- psychoticRabbit (3/7) Feb 12 2018 humans auditing the work of humans - what could be more dangerous
- Dmitry Olshansky (15/32) Feb 11 2018 Your customers if you have any. Brcause they is inevitably you
- psychoticRabbit (12/28) Feb 12 2018 "D is in a conflicted position regarding the bounds checking
- Ali (16/20) Feb 12 2018 Maybe I was missing the point, but isnt the objective or the
- Walter Bright (2/4) Feb 12 2018 Yes, with the focus on "incrementally".
- Dukc (13/17) Feb 11 2018 I think that at some point it should also be highlighted that
- rikki cattermole (2/21) Feb 11 2018 Out of interest will each! work here as well?
- Dukc (9/13) Feb 11 2018 Well, I just remembered that the Emscripten compiler did warn
- rikki cattermole (2/12) Feb 11 2018 :)
- Bastiaan Veelo (4/7) Feb 12 2018 should be "line 10" there.
- Seb (2/11) Feb 12 2018
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
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
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
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: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.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.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
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
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
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:That explains why there are so much SJW types in the Rust world :-)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
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
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: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.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
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
On Monday, 12 February 2018 at 04:30:38 UTC, psychoticRabbit wrote:On Sunday, 11 February 2018 at 15:18:20 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.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
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
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:Your customers if you have any. Brcause they is inevitably you one day.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.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
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."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!-boundscheck=off D rocks!
Feb 12 2018
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
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 controlYes, with the focus on "incrementally".
Feb 12 2018
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
On 11/02/2018 12:51 PM, Dukc wrote:On Wednesday, 7 February 2018 at 13:29:04 UTC, Mike Parker wrote:Out of interest will each! work here as well?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
On Sunday, 11 February 2018 at 12:56:34 UTC, rikki cattermole wrote: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.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.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
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
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
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:Answered (the same question was also asked on reddit. O_O)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.Your comment is awaiting moderation.
Feb 12 2018