Re:Debugging memory corruption: who the hell writes "2" into...
by ch33zer on Tuesday December 31, 2024 @05:09PM
(#42562229)
Doesn't C++ already support everything you need here? It supports the noexcept keyword which should have been used in the interface to this syscall. That would have prevented throwing callbacks from being used at compile time. My guess is that this is a much older syscall than noexcept though.
[ Parent
| on HN ]
Re:Debugging memory corruption: who the hell writes "2" into...
by cryptonector on Tuesday December 31, 2024 @06:05PM
(#42562537)
I think the PAPCFUNC type needs to have noexcept. Wrapping a function typedef in extern "C" does not make it imply noexcept IIRC.
It would also help if the APC docs documented that APCs must not throw.
Re:Debugging memory corruption: who the hell writes "2" into...
by ch33zer on Tuesday December 31, 2024 @07:42PM
(#42563017)
This would actually be a nice change (but probably very breaking) for c interfaces called from a c++ context to be implicitly noexcept.
Re:Debugging memory corruption: who the hell writes "2" into...
by ryao on Wednesday January 01, 2025 @04:18AM
(#42564930)
It is a C interface. It is implicitly noexcept. I filed bugs against both GCC and LLVM requesting warnings when someone passes a non-noexcept C++ function pointer to either a C function or to a C++ noexcept function:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118263
https://github.com/llvm/llvm-project/issues/121427
Perhaps the C++ standards committee should specify that doing this should cause a compiler failure, rather than a warning.
Re:Debugging memory corruption: who the hell writes "2" into...
by cryptonector on Wednesday January 01, 2025 @11:56AM
(#42567256)
Thanks for checking, clarifying, and filing those bugs!
Re:Debugging memory corruption: who the hell writes "2" into...
by masspro on Tuesday December 31, 2024 @05:34PM
(#42562358)
noexcept doesn’t prevent any throws at compile-time, it basically just wraps the function in a `catch(...)` block that will call std::terminate, like a failed assert. IMHO it is a stupid feature for this very confusion.
Re:Debugging memory corruption: who the hell writes "2" into...
by ch33zer on Tuesday December 31, 2024 @07:38PM
(#42562995)
This was true until c++17. It was changed in 17 to make noexcept part of the function type meaning a noexcept(false) function can't be used in a context where a noexcept is needed as they're unrelated types. I don't know if compilers actually implement this but according to the standard it should be usable.
Re:Debugging memory corruption: who the hell writes "2" into...
by masspro on Tuesday December 31, 2024 @07:56PM
(#42563080)
Yes this helps specifically when passing functions as pointers or something like std::function (edit: or overriding methods), it will at least inform the developer that they need to add noexcept to the function declaration if they want to use it there, and hopefully due to that they recursively audit the function body and anything it calls for exceptions. And hopefully all future developers also notice the noexcept and keep up the practice. But it changes nothing about checking plain function calls. So I think adding this to the function type helps some cases but still does not move noexcept toward the behavior most people want/expect.
This just feels important to point out because this feature is 15 years old and still commonly misunderstood, and each time people are wanting the same thing (actual compile-time prevention of `throw`) which it is not.
Re:Debugging memory corruption: who the hell writes "2" into...
by ryao on Wednesday January 01, 2025 @04:16AM
(#42564918)
If the compiler would just issue warnings in the following cases, then noexcept would be useful for preventing this problem:
https://godbolt.org/z/rjPfYjnzf
https://godbolt.org/z/14ocshsE5
I filed bugs against both GCC and LLVM requesting warnings: