On Thu, Jun 8, 2023 at 11:51 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Thu, Jun 08, 2023 at 10:20:19AM -0700, Nick Desaulniers wrote: > > Presumably, one could simply just not use RAII when working with a value that conditionally > > "escapes" the local scope. > > But then you're back to the error goto :/ Thinking more about the expected ergonomics here over lunch...no meaningful insights, just thoughts... For something like a mutex/lock; I'd expect those to be acquired then released within the same function, yeah? In which case __attribute__((cleanup())) has fewer hazards since the resource doesn't escape. For a pointer to a dynamically allocated region that may get returned to the caller... I mean, people do this in C++. It is safe and canonical to return a std::unique_ptr. When created locally the destructor does the expected thing regardless of control flow. IIUC, std::unique_ptr's move constructor basically does what Kees suggested earlier (trigger warning: C++): https://github.com/llvm/llvm-project/blob/7a52f79126a59717012d8039ef875f68e3c637fd/libcxx/include/__memory/unique_ptr.h#L429-L430. example: https://godbolt.org/z/51s49G9f1 A recent commit to clang https://reviews.llvm.org/rG301eb6b68f30 raised an interesting point (deficiency is perhaps too strong a word) about GNU-style attributes; they generally have no meaning on an ABI. Consider a function that returns a locally constructed std::unique_ptr. If the function returns a type where the caller knows what destructor functions to run. This is part of the ABI. Here, we're talking about using __attribute__((cleanup())) to DTR locally, but then we return a "raw" pointer to a caller. What cleanup function should the caller run, implicitly, if at all? If we use __attribute__((cleanup())) that saves us a few gotos locally, but the caller perhaps now needs the same treatment. -- Thanks, ~Nick Desaulniers
