3 ms·

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

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.

masspro 2y ago
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.
- sour-taste 2y ago
  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. https://en.cppreference.com/w/cpp/language/noexcept_spec https://en.cppreference.com/w/cpp/language/noexcept_spec
  - masspro 2y ago
    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. Edit: OK I finally just went and tried it on godbolt.org. C++17 GCC, Clang, and MSVC all give 1 warning on this code for `bar` and that's all. void canthrow() { throw 42; } void foo() noexcept { canthrow(); } void bar() noexcept { throw 42; }
    - deleted 2y ago
      [deleted]
    - ryao 2y ago
      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/rjPfYjnzf https://godbolt.org/z/14ocshsE5 https://godbolt.org/z/14ocshsE5 I filed bugs against both GCC and LLVM requesting warnings: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118263 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118263 https://github.com/llvm/llvm-project/issues/121427 https://github.com/llvm/llvm-project/issues/121427
cryptonector 2y ago
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.
- sour-taste 2y ago
  This would actually be a nice change (but probably very breaking) for c interfaces called from a c++ context to be implicitly noexcept.
- ryao 2y ago
  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://gcc.gnu.org/bugzilla/show_bug.cgi?id=118263 https://github.com/llvm/llvm-project/issues/121427 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.
  - cryptonector 2y ago
    Thanks for checking, clarifying, and filing those bugs!

masspro 2y ago

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.

sour-taste 2y ago
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. https://en.cppreference.com/w/cpp/language/noexcept_spec https://en.cppreference.com/w/cpp/language/noexcept_spec
- masspro 2y ago
  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. Edit: OK I finally just went and tried it on godbolt.org. C++17 GCC, Clang, and MSVC all give 1 warning on this code for `bar` and that's all. void canthrow() { throw 42; } void foo() noexcept { canthrow(); } void bar() noexcept { throw 42; }
  - deleted 2y ago
    [deleted]
  - ryao 2y ago
    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/rjPfYjnzf https://godbolt.org/z/14ocshsE5 https://godbolt.org/z/14ocshsE5 I filed bugs against both GCC and LLVM requesting warnings: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118263 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118263 https://github.com/llvm/llvm-project/issues/121427 https://github.com/llvm/llvm-project/issues/121427

cryptonector 2y ago

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.

sour-taste 2y ago
This would actually be a nice change (but probably very breaking) for c interfaces called from a c++ context to be implicitly noexcept.
ryao 2y ago
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://gcc.gnu.org/bugzilla/show_bug.cgi?id=118263 https://github.com/llvm/llvm-project/issues/121427 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.
- cryptonector 2y ago
  Thanks for checking, clarifying, and filing those bugs!