Hacker News Reader

Comment by dataflow | Hacker News Reader

I assume the /EHr- flag was introduced to mitigate this, right?

Nah that was mostly about extern "C" functions which technically can't throw (so the noexcept runtime stuff would be optimized out) but in practice there is a ton of code marked extern "C" which throws

extern "C" seems related to the other flags, not 'r'?

Well, yeah, things can be related to many things, but throwing extern "C"s was one of the motivations as I recall for 'r'. r is about a compiler optimization where we elide the runtime terminate check if we can statically "prove" a function can never throw. To prove it statically we depend on things like extern "C" functions not throwing, even though users can (and do) totally write that code.

> in practice there is a ton of code marked extern "C" which throws

Obviously, a random programmer could do any evil things, but does that apply to standard code, such as C standard library used from C++?

Yes, qsort and bsearch can throw.

jfc... Can you give more info how did you learn this and to which lib implementation this applies?

Well, given that qsort and bsearch take a function pointer and call it, that function pointer can easily point to a function that throws. So I think this applies to all implementations of qsort and bsearch. Especially since there is no way to mark a function pointer as noexcept.

> Especially since there is no way to mark a function pointer as noexcept.

There is, noexcept is part of the type since C++17. In fact, I prefer noexcept function pointer parameters for C library wrappers, as I don't expect most libraries written in C to deal with stack unwinding at all.

Oops, you're right, I hadn't checked that this had changed in C++ 17.

https://eel.is/c++draft/alg.c.library#4

Any library implementation that is C++ compliant must implement this. I'm pretty sure that libstdc++ + glibc is compliant, assuming sane glibc compiler options.

a perfect answer, thank you!

but to me these are - again - a user induced problems. I'm interested if a user doesn't do stupid things, should they still afraid that a standard extern C code could throw? Say, std::sprintf() which if I'm not mistaken boils down to C directly? Are there cases where C std lib could throw without a "help from a user"?

https://eel.is/c++draft/res.on.exception.handling#2

I general functions from the C standard library must not throw, except for the ones taking function pointers that they execute.

perfect again, thank you!

I don't think anything in the C parts of the C++ standard library throws its own exceptions. However, it's not completely unreasonable for a third party C library to use a C++ library underneath, and that might propagate any exceptions that the C++ side throws. This would be especially true if the C library were designed with some kind of plugin support, and someone supplied a C++ plugin.

Reply on news.ycombinator.com