digitalmars.D - Curiously Recurring C++ Bugs
- Walter Bright (3/3) Jul 11 https://www.youtube.com/watch?v=lkgszkPnV8g
- Timon Gehr (34/39) Jul 11 Well, the situation in D is overall much better, but I wouldn't say it
- Walter Bright (29/64) Jul 12 `-release` hasn't turned of bounds checking for something like 15 years....
- Timon Gehr (37/93) Jul 12 ```d
- Walter Bright (2/3) Jul 12 It'll give the bounds check error for @safe code even with -release.
- Timon Gehr (6/14) Jul 12 I am aware. In C++ you can get the bounds check with std::vector::at.
- cc (7/9) Jul 19 This is very interesting because until this past week or so I
- Paul Backus (5/14) Jul 19 -release includes -boundscheck=safeonly, which turns off bounds
- monkyyy (3/7) Jul 11 d is buggy and there are several things I believe cant be fixed
- =?UTF-8?Q?Ali_=C3=87ehreli?= (6/11) Aug 02 It was a bonus slide in one of my meetup presentations. It comes with
- Walter Bright (4/10) Aug 03 Haha, a response to the same cppcon talk!
https://www.youtube.com/watch?v=lkgszkPnV8g This is a great talk. In my first pass, D doesn't suffer from any of them. Anyone want to verify?
Jul 11
On 7/11/24 22:36, Walter Bright wrote:https://www.youtube.com/watch?v=lkgszkPnV8g This is a great talk. In my first pass, D doesn't suffer from any of them. Anyone want to verify?Well, the situation in D is overall much better, but I wouldn't say it does not suffer from any of them. - std::vector::operator[]: D code still suffers from unrecoverable range errors that would crash the website, it's just not a memory safety issue unless you pass badly designed compiler flags like `-release`. - std::map::operator[]: Not a problem in D. - get_default(): Potential for lifetime error fixed with DIP1000. Still potentially a performance problem in D without DIP1040. - volatile: Not clear, but I guess `volatile` is less popular nowadays. https://dlang.org/phobos/core_volatile.html D also does not have a full `shared` story so far. - shared_ptr thread-safe: Potentially fixed because D has transitive `shared`. But again, `shared` is unfinished. Or use GC. - shared_ptr bonus bug: Simple pattern like the one on the slide seem superficially fixable with DIP1000, but in general in D it is not possible to make smart pointer dereferencing safe. Can use GC though. - lock bug: That syntax would not lock until the end of the scope in D either, but for different reasons. But there is no reason to expect it would work, so I guess we can consider this fixed in D. I guess the lessons are: - D also does not have static typing to rule out range errors. - D also does not have memory safety for general allocator-backed container types. - remove `-release` - implement DIP1040. - finalize `shared`.
Jul 11
On 7/11/2024 3:39 PM, Timon Gehr wrote:- std::vector::operator[]: D code still suffers from unrecoverable range errors that would crash the website, it's just not a memory safety issue unless you pass badly designed compiler flags like `-release`.`-release` hasn't turned of bounds checking for something like 15 years. To disable it, `-noboundscheck` is required. What a range check error does can be set with the `-checkaction` switch: -checkaction=[D|C|halt|context] behavior on assert/boundscheck/finalswitch failure- std::map::operator[]: Not a problem in D. - get_default(): Potential for lifetime error fixed with DIP1000. Still potentially a performance problem in D without DIP1040. - volatile: Not clear, but I guess `volatile` is less popular nowadays. https://dlang.org/phobos/core_volatile.htmlThose are special functions, and the documentation is explicit about what they are for, and not for, and atomic operations are in the "not" category. They are not part of the type system of the language.D also does not have a full `shared` story so far.It's a far better story than C++ has.- shared_ptr thread-safe: Potentially fixed because D has transitive `shared`. But again, `shared` is unfinished. Or use GC.- shared_ptr bonus bug: Simple pattern like the one on the slide seem superficially fixable with DIP1000, but in general in D it is not possible to make smart pointer dereferencing safe.It is possible by blocking any attempts at bypassing the interface of it.Can use GC though.Yup. Not the unsafe mess shared_ptr is.- lock bug: That syntax would not lock until the end of the scope in D either, but for different reasons. But there is no reason to expect it would work, so I guess we can consider this fixed in D.Unmentioned is the "if it looks like a declaration it is one" ambiguity bug, that featured fairly prominently in the talk. D does not allow: ``` void test() { int (x); } ``` Error: undefined identifier `x` as a declaration of x.I guess the lessons are: - D also does not have static typing to rule out range errors.I don't understand that. If you have resizeable arrays, static typing is not going to give you compile time guarantees. D does allow static arrays, which can rule out range errors for statically known indices.- D also does not have memory safety for general allocator-backed container types.That wasn't in his talk.- implement DIP1040.We'll be moving forward with that.- finalize `shared`.The idea is to disallow use of shared if it cannot be done atomically - std.atomic would need to be used.
Jul 12
On 7/12/24 22:13, Walter Bright wrote:On 7/11/2024 3:39 PM, Timon Gehr wrote:```d void main(){ auto a=[1,2,3]; a[3]=2; } ``` ```bash $ dmd -run tt core.exception.ArrayIndexError tt.d(4): index [3] is out of bounds for array of length 3 ---------------- ??:? onArrayIndexError [0x5a712bff44b2] ??:? _d_arraybounds_indexp [0x5a712bff180f] ??:? _Dmain [0x5a712bff1780] ``` ```bash dmd -release -run tt ``` (crickets.)- std::vector::operator[]: D code still suffers from unrecoverable range errors that would crash the website, it's just not a memory safety issue unless you pass badly designed compiler flags like `-release`.`-release` hasn't turned of bounds checking for something like 15 years. To disable it, `-noboundscheck` is required. ......I am aware.- volatile: Not clear, but I guess `volatile` is less popular nowadays. https://dlang.org/phobos/core_volatile.htmlThose are special functions, and the documentation is explicit about what they are for, and not for, and atomic operations are in the "not" category. They are not part of the type system of the language. ...I acknowledged as much at the beginning of my post. I like D and I dislike C++.D also does not have a full `shared` story so far.It's a far better story than C++ has. ...Well, the example was specifically about the dereference operator returning by `ref`.- shared_ptr thread-safe: Potentially fixed because D has transitive `shared`. But again, `shared` is unfinished. Or use GC.- shared_ptr bonus bug: Simple pattern like the one on the slide seem superficially fixable with DIP1000, but in general in D it is not possible to make smart pointer dereferencing safe.It is possible by blocking any attempts at bypassing the interface of it. ...It can do that. Neither D nor C++, nor other particularly popular languages are doing it yet though. There are entire compilers that have been verified for functional correctness by the type systems of their implementation languages. This in particular includes absence of runtime errors, which is not even prone to misspecification errors.I guess the lessons are: - D also does not have static typing to rule out range errors.I don't understand that. If you have resizeable arrays, static typing is not going to give you compile time guarantees....`shared_ptr` was in the talk. The language-level safety challenges remain basically the same, whether you build your data structures out of `shared_ptr`s or not.- D also does not have memory safety for general allocator-backed container types.That wasn't in his talk. ......At the moment, basic druntime synchronization functionality does not compile with `-preview=nosharedaccess`. Class references cannot be tail-`shared`. etc.- finalize `shared`.The idea is to disallow use of shared if it cannot be done atomically - std.atomic would need to be used.
Jul 12
On 7/12/2024 2:16 PM, Timon Gehr wrote:(crickets.)It'll give the bounds check error for safe code even with -release.
Jul 12
Timon Gehr <timon.gehr gmx.ch> On 7/13/24 01:25, Walter Bright wrote:On 7/12/2024 2:16 PM, Timon Gehr wrote:I am aware. In C++ you can get the bounds check with std::vector::at. Anyway, your point was: On 7/12/24 22:13, Walter Bright wrote:(crickets.)It'll give the bounds check error for safe code even with -release.`-release` hasn't turned of bounds checking for something like 15 years. To disable it, `-noboundscheck` is required.This is false. Nothing else is required to turn off some bounds checks with `-release`, escalating out-of-bounds accesses to a memory safety issue.
Jul 12
On Friday, 12 July 2024 at 20:13:24 UTC, Walter Bright wrote:`-release` hasn't turned of bounds checking for something like 15 years. To disable it, `-noboundscheck` is required.This is very interesting because until this past week or so I thought -release implied -noboundscheck as well. I think I've been using D around 8 or 9 years now. I had already stopped using -release some time ago, but nonetheless, whatever documentation there was for those command line args must have been veeery slow to catch up to reality.
Jul 19
On Friday, 19 July 2024 at 14:34:33 UTC, cc wrote:On Friday, 12 July 2024 at 20:13:24 UTC, Walter Bright wrote:-release includes -boundscheck=safeonly, which turns off bounds checking in system and trusted code. Most D code is not (yet) safe, so the result is that most D code will have its bounds checks removed when using -release.`-release` hasn't turned of bounds checking for something like 15 years. To disable it, `-noboundscheck` is required.This is very interesting because until this past week or so I thought -release implied -noboundscheck as well. I think I've been using D around 8 or 9 years now. I had already stopped using -release some time ago, but nonetheless, whatever documentation there was for those command line args must have been veeery slow to catch up to reality.
Jul 19
On Thursday, 11 July 2024 at 20:36:35 UTC, Walter Bright wrote:https://www.youtube.com/watch?v=lkgszkPnV8g This is a great talk. In my first pass, D doesn't suffer from any of them. Anyone want to verify?d is buggy and there are several things I believe cant be fixed without a major rewrites; it wont be any good to pretend otherwise
Jul 11
On 7/11/24 1:36 PM, Walter Bright wrote:https://www.youtube.com/watch?v=lkgszkPnV8g This is a great talk. In my first pass, D doesn't suffer from any of them. Anyone want to verify?It was a bonus slide in one of my meetup presentations. It comes with horrible audio and speaker accent but here it is: https://youtu.be/qrxxgYwU1X0?t=903 Ali "yes, alive"
Aug 02
On 8/2/2024 8:07 PM, Ali Çehreli wrote:It was a bonus slide in one of my meetup presentations. It comes with horrible audio and speaker accent but here it is: https://youtu.be/qrxxgYwU1X0?t=903Haha, a response to the same cppcon talk! Would you consider re-recording it?Ali "yes, alive"Glad to hear it!
Aug 03