5 ms·

The bug report says that the lambda pointer is dangling and is leaked. I’m not at my computer atm so i can’t tell which this is (by my definition dangling = sec

by olliej 4y ago

The bug report says that the lambda pointer is dangling and is leaked. I’m not at my computer atm so i can’t tell which this is (by my definition dangling = security bug, leak = annoying, both are bad the former is obviously much worse), my intuition is that it’s a dangling reference but not in a position to see codegen (I’d guess something similar occurs in clang if it’s spec behaviour). Given that this is the obvious use case I feel that this would be worth fixing in the spec before widespread adoption. That all said it demonstrates the issues with a lot of new c++ features, in that even today new features are added without real thought to memory safety. There were a couple of proposals to at least make it possible to specify lifetime constraints, even if they’d only be warnings initially, but they died because memory safety remains a lower priority than other sexier features. Like I really do love c++, but memory safety has to become higher priority than other features for a while.

notacoward 4y ago
This is what always seems to happen when systems only grow and never shrink. Later-added features don't always play well with each other, even when they're added sequentially and it seems like they should. It's technical debt at the specification level (as opposed to code) and I've seen it bite more projects than I can count. Sometimes you just have to start swinging the axe, or else stop wasting effort and plan migration to an alternative. In this case the alternative seems to be Rust, and no, I'm not a Rust advocate. Far from it, in fact. Personally I find Zig and several others more appealing. However, I also feel that the state of the art will advance more quickly if the C++ programmers migrate to any of those alternatives, and Rust seems pretty far ahead as the direct successor.
selfmodruntime 4y ago
> That all said it demonstrates the issues with a lot of new c++ features, in that even today new features are added without real thought to memory safety I would go much further than that and claim that there are new C++ features added without real thought to other features. The C++ feature list is so incredibly vast that language maintainers / spec writers would need to know every little intricacy of other features to assert that a combination would still produce correct output.
- AlotOfReading 4y ago
  The problem is so much worse than that. Combining even the most fundamental features of the language (like UB and concurrency) leads to dark corners where even experts like Boehm aren't sure. The recent TR about safety-critical C++ is basically "don't use C++", which is correct, but not particularly helpful. The reality is that the standard simply isn't a good enough reference for what the language does. If you care about that, you need to treat programming in it as an experimental endeavor where you validate that your particular combination of code + toolchain + hardware does what you want. It's nice if the standard goes along for the ride, but not something you can rely on.
- asveikau 4y ago
  We're now 11 years from c++11, but I wanted to say lambdas are generally well thought out with respect to how memory management works in c++. The syntax for captures is weird at first, but once you appreciate that what it's doing is playing nice with copy constructors, it's good.
  - gpderetta 4y ago
    Yes, lambdas are by far one of the best things to come out of the last 20 years of C++ development. They work exactly as a C++ programmer would expect (i.e. they are equivalent to a manually written struct overloading operator()). Coroutines, IMHO not so much; they are extremely complex and feel half baked. The problem is that there was so much discussion around them, that it was either that or nothing for the next 10 years.
masklinn 4y ago
In fairness, features which break one another are not a new thing in C++. > they died because memory safety remains a lower priority than other sexier features. Is it a priority at all? Or is it on a list titled "¡" under a cabinet in the disused toilets of the third basement? I don't know whether 20 did as well, but C++17 literally added explicitely anti-memory-safety features (std::optional).
- kllrnohj 4y ago
  > but C++17 literally added explicitely anti-memory-safety features (std::optional) How did you reach the very odd conclusion that std::optional is "anti-memory-safe"?
  - masklinn 4y ago
    Because the committee took something which is normally a way to lift nullability into the type system and make pointers null-safe, and instead made it… a nullable pointer. With all the absence of safety of a C++ pointer.
    - jcelerier 4y ago
      > Because the committee took something which is normally a way to lift nullability into the type system and make pointers null-safe, and instead made it… a nullable pointer. With all the absence of safety of a C++ pointer. anything that adds a branch to check dereference in release builds is an instant no-go, what do you propose to do instead?
      - CJefferson 4y ago
        Why is it a no-go? If you mark the check as "unlikely" the cost is extremely small, and maybe we should just pay the cost rather than have undefined behaviour.
        jcelerier 4y ago

by olliej 4y ago

notacoward 4y ago

This is what always seems to happen when systems only grow and never shrink. Later-added features don't always play well with each other, even when they're added sequentially and it seems like they should. It's technical debt at the specification level (as opposed to code) and I've seen it bite more projects than I can count. Sometimes you just have to start swinging the axe, or else stop wasting effort and plan migration to an alternative. In this case the alternative seems to be Rust, and no, I'm not a Rust advocate. Far from it, in fact. Personally I find Zig and several others more appealing. However, I also feel that the state of the art will advance more quickly if the C++ programmers migrate to any of those alternatives, and Rust seems pretty far ahead as the direct successor.

selfmodruntime 4y ago

> That all said it demonstrates the issues with a lot of new c++ features, in that even today new features are added without real thought to memory safety I would go much further than that and claim that there are new C++ features added without real thought to other features. The C++ feature list is so incredibly vast that language maintainers / spec writers would need to know every little intricacy of other features to assert that a combination would still produce correct output.

AlotOfReading 4y ago
The problem is so much worse than that. Combining even the most fundamental features of the language (like UB and concurrency) leads to dark corners where even experts like Boehm aren't sure. The recent TR about safety-critical C++ is basically "don't use C++", which is correct, but not particularly helpful. The reality is that the standard simply isn't a good enough reference for what the language does. If you care about that, you need to treat programming in it as an experimental endeavor where you validate that your particular combination of code + toolchain + hardware does what you want. It's nice if the standard goes along for the ride, but not something you can rely on.
asveikau 4y ago
We're now 11 years from c++11, but I wanted to say lambdas are generally well thought out with respect to how memory management works in c++. The syntax for captures is weird at first, but once you appreciate that what it's doing is playing nice with copy constructors, it's good.
- gpderetta 4y ago
  Yes, lambdas are by far one of the best things to come out of the last 20 years of C++ development. They work exactly as a C++ programmer would expect (i.e. they are equivalent to a manually written struct overloading operator()). Coroutines, IMHO not so much; they are extremely complex and feel half baked. The problem is that there was so much discussion around them, that it was either that or nothing for the next 10 years.

masklinn 4y ago

In fairness, features which break one another are not a new thing in C++. > they died because memory safety remains a lower priority than other sexier features. Is it a priority at all? Or is it on a list titled "¡" under a cabinet in the disused toilets of the third basement? I don't know whether 20 did as well, but C++17 literally added explicitely anti-memory-safety features (std::optional).

kllrnohj 4y ago
> but C++17 literally added explicitely anti-memory-safety features (std::optional) How did you reach the very odd conclusion that std::optional is "anti-memory-safe"?
- masklinn 4y ago
  Because the committee took something which is normally a way to lift nullability into the type system and make pointers null-safe, and instead made it… a nullable pointer. With all the absence of safety of a C++ pointer.
  - jcelerier 4y ago
    > Because the committee took something which is normally a way to lift nullability into the type system and make pointers null-safe, and instead made it… a nullable pointer. With all the absence of safety of a C++ pointer. anything that adds a branch to check dereference in release builds is an instant no-go, what do you propose to do instead?
    - CJefferson 4y ago
      Why is it a no-go? If you mark the check as "unlikely" the cost is extremely small, and maybe we should just pay the cost rather than have undefined behaviour.
      - jcelerier 4y ago