Curiously Recurring C++ Bugs

Walter Bright newshound2 at digitalmars.com
Fri Jul 12 20:13:24 UTC 2024


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.html

Those 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.


More information about the Digitalmars-d mailing list