3 ms·

Good luck not releasing stack frames.

mgaunard 2y ago
Talked like somebody that doesn't understand the stack at all. On Linux, the stack grows automatically and never shrinks.
- leni536 2y ago
  Sure, the stack as storage never shrinks, but it's constantly reused for different kinds of objects. Having said that dynamic memory is also rarely given back to the OS, and you are lucky to get a segfault from a use-after-free there too. This is not the problem. The problem is accessing objects that are outside of their lifetime, not storage. The objects are gone, even if the storage might still be there.
  - mgaunard 2y ago
    That's not as big of a problem as using more resources than you need.
- UncleMeat 2y ago
  Use-after-return is a subset of use-after-free bugs. Allocate a temporary on the stack, pass it by reference to somewhere that outlives that function, and then watch your program explode. No dynamic memory allocation at all.
  - kiitos 2y ago
    Escape analysis can easily determine if a temporary/local value that would by default be allocated on the stack outlives the function in which it was declared, and in that case can move the allocation to the heap instead.
    - UncleMeat 2y ago
      Sort of. If your approach is "never free things" then you probably want to know pretty clearly what allocations will produce leaks and a sound escape analysis is going to definitely report some allocations that are unexpected. But this isn't the hard part. Since you need to edit your compile to modify allocations, this needs to be a global analysis. If you've got a function that takes a parameter by reference and returns it by reference, you need to adjust the allocations at the call site to be on the heap if the return value outlives the allocation. But... now you've broken separate compilation and need this to run as a global pass with lto. And enjoy all of your false positives caused by sound call graph analysis in a world where you've got virtual and indirect function calls. And what about a local that is stored by reference as a field of an object and then that object is passed by reference to a function? Now you need an object-sensitive pointer analysis. During your compile. And then there are all of the ordinary problems with C++ that make sound static analysis nightmarish. One of these things havocs and blows everything up to Top and you are quickly yelling at your compiler.
      - kiitos 2y ago
        I dunno, Go does it pretty effectively, are they cheating or something?

Talked like somebody that doesn't understand the stack at all. On Linux, the stack grows automatically and never shrinks.

leni536 2y ago
Sure, the stack as storage never shrinks, but it's constantly reused for different kinds of objects. Having said that dynamic memory is also rarely given back to the OS, and you are lucky to get a segfault from a use-after-free there too. This is not the problem. The problem is accessing objects that are outside of their lifetime, not storage. The objects are gone, even if the storage might still be there.
- mgaunard 2y ago
  That's not as big of a problem as using more resources than you need.
UncleMeat 2y ago
Use-after-return is a subset of use-after-free bugs. Allocate a temporary on the stack, pass it by reference to somewhere that outlives that function, and then watch your program explode. No dynamic memory allocation at all.
- kiitos 2y ago
  Escape analysis can easily determine if a temporary/local value that would by default be allocated on the stack outlives the function in which it was declared, and in that case can move the allocation to the heap instead.
  - UncleMeat 2y ago
    Sort of. If your approach is "never free things" then you probably want to know pretty clearly what allocations will produce leaks and a sound escape analysis is going to definitely report some allocations that are unexpected. But this isn't the hard part. Since you need to edit your compile to modify allocations, this needs to be a global analysis. If you've got a function that takes a parameter by reference and returns it by reference, you need to adjust the allocations at the call site to be on the heap if the return value outlives the allocation. But... now you've broken separate compilation and need this to run as a global pass with lto. And enjoy all of your false positives caused by sound call graph analysis in a world where you've got virtual and indirect function calls. And what about a local that is stored by reference as a field of an object and then that object is passed by reference to a function? Now you need an object-sensitive pointer analysis. During your compile. And then there are all of the ordinary problems with C++ that make sound static analysis nightmarish. One of these things havocs and blows everything up to Top and you are quickly yelling at your compiler.
    - kiitos 2y ago
      I dunno, Go does it pretty effectively, are they cheating or something?