4 ms·

Unless you use shared_ptr for all heap allocations (and are also careful about references to stack-allocated data) it allows for uaf bugs. And at that point you

Unless you use shared_ptr for all heap allocations (and are also careful about references to stack-allocated data) it allows for uaf bugs. And at that point you are probably better off with a GC since you've got all of the problems with a reference-counting GC but none of the opportunities for optimization.

FpUser 4y ago
Modern C++ provides enough nuts and bolts to avoid explicit allocations. My current C++ project (backend business server) only has single one. The rest is handled happily by RAII (what a dumb name). I could eliminate that single explicit allocation as well but I think I could manage single occurrence ;). Also It would be really dumb to use shared_ptr for every case of allocation
- UncleMeat 4y ago
  "I only every allocate things on the stack" is not sufficient to have safe lifetime access. I've seen enough cases of some stack-allocated string getting passed as a string_view and then blowing up because somebody stored it. "I have a complete tree of object ownership with a single allocated root" is also a mess for a different reason - you literally never delete anything. Either you have a very very strange application or you are being massively wasteful with memory pressure. It would be really dumb to use shared_ptr for every allocation. But it is the only way in C++ to systematically ensure that you never have a uaf (I guess you could also have a custom allocator and a custom pointer type that does a null check on every dereference - but now you are paying a major performance cost for a lock and a branch on every dereference). That's why I mention the benefit of a GC. You can get safe lifetime access without shared_ptr everywhere (or going all the way to where Rust went and demanding very explicit lifetime annotations for the compiler to use).
  - FpUser 4y ago
    >"I've seen enough cases of some stack-allocated string getting passed as a string_view and then blowing up because somebody stored it ..." Shortest answer - I do not get scared into using particular tools just because they're "safe" and in practice I've never had to deal with the problems you mentioned in my products. There are also various tools that catch these kinds of errors for C++ and other languages. I do use those them tools ;)
    - UncleMeat 4y ago
      A major part of my career has been to write these tools. There's a reason why none of them are sound. I do not believe that modern C++ and the surrounding tool ecosystem is remotely capable of preventing UAF bugs in complex applications, which is a big problem for many applications given the potential consequences of incorrect memory access. You might belong to the rarified class of uber-developers who can write bug-free C++ applications, but if that class of people exists it is a small one.
      - FpUser 4y ago
        >"A major part of my career has been to write these tools. There's a reason why none of them are sound." This is an interesting take coming from a person who writes the tools. Obviously you know way more about it. I do understand that if I for example link ASAN and it does not show errors for a while it is not a guarantee. The software just might not hit that error path. But I am a practical man running my own company and can not be a perfectionist. If software passes my own test, analyzers and other tools do not report anything suspicious and I have no bug reports from a customer I can sleep well and count my money ;) >"You might belong to the rarified class of uber-developers who can write bug-free C++ applications" I absolutely do not write bug free applications but I tend to have very few to begin with and I do eradicate them pretty fast. Some of my stable releases run for years without any bug related complaints. Not sure if that qualifies for "uber". I am however very good architect and deliver solutions in very diverse areas. Desktop, multimedia, enterprise backends, middleware, device control firmware etc. Also understand electronics.
        UncleMeat 4y ago
        I'm on the static side. The sanitizers are indeed great tools but they are mostly too performance-costly to run in production environments, so they just exist for your tests and maybe for some small percentage of your production environment. Deployed in this manner, it isn't going to catch everything. I think that asan is also theoretically unsound (I don't know its innards well enough) based on how it actually tags pages but in practice this isn't super relevant. The question is whether you actually execute the problematic sequence in some build that has asan enabled. > Not sure if that qualifies for "uber". Writing C++ code with minimal memory errors would qualify as "uber", given the data available from both academic and industrial research on C++ application development. The data is very clear - real applications run into these issues with frequency even when they consistently use modern smart pointers.
moloch-hai 4y ago
shared_ptr use is very rare in good modern C++. Uaf bugs are much rarer. Most people using modern C++ never have any, see any, or risk any. So, no, they would not be better off with GC.
- UncleMeat 4y ago
  > shared_ptr use is very rare in good modern C++ That's true. But if you do the preferred thing of using unique_ptr then you still happily access memory beyond the lifetime of an object via some bug. > Uaf bugs are much rarer. This is not true. You can go look at CVEs for large projects like Chrome that have teams of people trying to weed out these kinds of issues and still see UAFs where absolutely nothing is allocated with "new."
  - moloch-hai 4y ago
    That's Google for you. You cannot access memory you have no pointer to, not even accidentally.
    - UncleMeat 4y ago
      "Never hand out non-owning pointers or references" is not, in my opinion, an acceptable design constraint for a tremendous number of systems.
      - moloch-hai 4y ago
        Hand them out freely. Don't store them. Likewise, string_view. The go down the call chain, not up.

FpUser 4y ago

Modern C++ provides enough nuts and bolts to avoid explicit allocations. My current C++ project (backend business server) only has single one. The rest is handled happily by RAII (what a dumb name). I could eliminate that single explicit allocation as well but I think I could manage single occurrence ;). Also It would be really dumb to use shared_ptr for every case of allocation

UncleMeat 4y ago
"I only every allocate things on the stack" is not sufficient to have safe lifetime access. I've seen enough cases of some stack-allocated string getting passed as a string_view and then blowing up because somebody stored it. "I have a complete tree of object ownership with a single allocated root" is also a mess for a different reason - you literally never delete anything. Either you have a very very strange application or you are being massively wasteful with memory pressure. It would be really dumb to use shared_ptr for every allocation. But it is the only way in C++ to systematically ensure that you never have a uaf (I guess you could also have a custom allocator and a custom pointer type that does a null check on every dereference - but now you are paying a major performance cost for a lock and a branch on every dereference). That's why I mention the benefit of a GC. You can get safe lifetime access without shared_ptr everywhere (or going all the way to where Rust went and demanding very explicit lifetime annotations for the compiler to use).
- FpUser 4y ago
  >"I've seen enough cases of some stack-allocated string getting passed as a string_view and then blowing up because somebody stored it ..." Shortest answer - I do not get scared into using particular tools just because they're "safe" and in practice I've never had to deal with the problems you mentioned in my products. There are also various tools that catch these kinds of errors for C++ and other languages. I do use those them tools ;)
  - UncleMeat 4y ago
    A major part of my career has been to write these tools. There's a reason why none of them are sound. I do not believe that modern C++ and the surrounding tool ecosystem is remotely capable of preventing UAF bugs in complex applications, which is a big problem for many applications given the potential consequences of incorrect memory access. You might belong to the rarified class of uber-developers who can write bug-free C++ applications, but if that class of people exists it is a small one.
    - FpUser 4y ago
      >"A major part of my career has been to write these tools. There's a reason why none of them are sound." This is an interesting take coming from a person who writes the tools. Obviously you know way more about it. I do understand that if I for example link ASAN and it does not show errors for a while it is not a guarantee. The software just might not hit that error path. But I am a practical man running my own company and can not be a perfectionist. If software passes my own test, analyzers and other tools do not report anything suspicious and I have no bug reports from a customer I can sleep well and count my money ;) >"You might belong to the rarified class of uber-developers who can write bug-free C++ applications" I absolutely do not write bug free applications but I tend to have very few to begin with and I do eradicate them pretty fast. Some of my stable releases run for years without any bug related complaints. Not sure if that qualifies for "uber". I am however very good architect and deliver solutions in very diverse areas. Desktop, multimedia, enterprise backends, middleware, device control firmware etc. Also understand electronics.
      - UncleMeat 4y ago
        I'm on the static side. The sanitizers are indeed great tools but they are mostly too performance-costly to run in production environments, so they just exist for your tests and maybe for some small percentage of your production environment. Deployed in this manner, it isn't going to catch everything. I think that asan is also theoretically unsound (I don't know its innards well enough) based on how it actually tags pages but in practice this isn't super relevant. The question is whether you actually execute the problematic sequence in some build that has asan enabled. > Not sure if that qualifies for "uber". Writing C++ code with minimal memory errors would qualify as "uber", given the data available from both academic and industrial research on C++ application development. The data is very clear - real applications run into these issues with frequency even when they consistently use modern smart pointers.

moloch-hai 4y ago

shared_ptr use is very rare in good modern C++. Uaf bugs are much rarer. Most people using modern C++ never have any, see any, or risk any. So, no, they would not be better off with GC.

UncleMeat 4y ago
> shared_ptr use is very rare in good modern C++ That's true. But if you do the preferred thing of using unique_ptr then you still happily access memory beyond the lifetime of an object via some bug. > Uaf bugs are much rarer. This is not true. You can go look at CVEs for large projects like Chrome that have teams of people trying to weed out these kinds of issues and still see UAFs where absolutely nothing is allocated with "new."
- moloch-hai 4y ago
  That's Google for you. You cannot access memory you have no pointer to, not even accidentally.
  - UncleMeat 4y ago
    "Never hand out non-owning pointers or references" is not, in my opinion, an acceptable design constraint for a tremendous number of systems.
    - moloch-hai 4y ago
      Hand them out freely. Don't store them. Likewise, string_view. The go down the call chain, not up.