5 ms·

Basically, this! Most of the OP's points are valid, no denying that. But, looking at the myriads of properly working, fast, not 'exploding in your face at runt

• stcredzero 11y ago
  doesn't really seem like a poblem if one knows how to deal with it And that is the downfall of all programming languages/paradigms!
• pcwalton 11y ago
  > But, looking at the myriads of properly working, fast, not 'exploding in your face at runtime' Does remote code execution due to use after free fall in the category of "properly working" and "exploding in your face at runtime"? I would think it does, and C++ is vulnerable to that like few other languages are.
  • dragontamer 11y ago
    Why are you using "free" in modern C++ code? That was mostly put in there as a transition from C. Modern C++ users shouldn't be using new / free at all, since shared_ptr (and weak_ptr, its counterpart) and unique_ptr basically cover all the use cases.
    • pcwalton 11y ago
      Whether you actually call "free" doesn't matter. You're falling victim to the "smart pointers/modern C++ is memory safe" fallacy. It is not, for reasons I've elaborated on at length numerous times before.
      • dragontamer 11y ago
        So are you going to elaborate again or post a blogpost of your points? Its hard to hold a discussion if the other side doesn't... discuss... things.
        • pcwalton 11y ago
          std::vector<std::string> v; v.push_back("Hello"); for (auto&& s: v) { v.clear(); std::cout << s; // use after free in modern C++ } There is no reasonable way for a compiler to precisely check for use after free in C++ short of changing the language, and this can be easily proven.
          • dragontamer 11y ago
            Technically, that's a iterator invalidation and those are indeed hard to keep track of. There are runtime libraries that keep track of pointer-invalidation for you however. In any case, a std::vector<shared_ptr<std::string> > would actually avoid the issue in this particular case. Use after free... is more about use of raw pointers IMO. I wouldn't describe that code to be a "use after free" at all. In most languages, you are simply not allowed to change the container at all. Iterator invalidation is a hard issue in any language.
            • pcwalton 11y ago
              Iterator invalidation does not result in remote code execution in other languages. Regardless of what you call it (and you are in the minority by not considering that code UAF) the result is the same when combined with vtables and attacker-influenced heaps: arbitrary code execution. shared_ptr is also not memory safe when combined with references, which you need to use to call methods on the shared_ptr'd object or to pass those objects to most functions.
            • gpderetta 11y ago
              Tecnically that's reference invalidation and no pure library is going to help you. You need compiler/runtime help (i.e. static analysis or some sort of sanitizer).
    • maccard 11y ago
      I don't think the parent meant free as in "free()" - more along the lines of. Foo f; DoSomething(std::move(f)); // can still use f here.
      • deleted 11y ago
        [deleted]
      • dragontamer 11y ago
        But if "Foo" was composed of unique_ptr (or shared_ptr), then those smart pointers would be nulled out after the std::move (due to the default move constructor) So again, unless Foo f was composed of "raw pointers", even that kind of code is safe from "use after free" vulnerabilities.
  • stinos 11y ago
    Does remote code execution due to use after free fall in the category of "properly working" and "exploding in your face at runtime"? I would think it does Not exactly. Use after free, while indeed problematic, is not what I would consider proper code, and I think you're well aware of that :]
• jobu 11y ago
  Yeah, after fifteen years of C/C++ I can say most of those complaints are minor, have easy workarounds, or can be ignored when doing general-use programming.