As far as I can see this is undefined behaviour because youre throwing an exception through C linkage which the stack unwinding/exception propagation process doesn't have to be able to do.
Posted Jul 4, 2012 15:10 UTC (Wed) by nix (subscriber, #2304)
[Link]
It's not undefined behaviour so much as it might just not work. Some functions in glibc (e.g. qsort()) are explicitly compiled with -fexceptions so as to support C++ exceptions thrown through qsort() from the callback function, but this is very rare: I've never seen it in C code outside glibc, even for C functions that invoke callbacks.
C vs. C++ vs. ...
Posted Jul 4, 2012 15:17 UTC (Wed) by andresfreund (subscriber, #69562)
[Link]
Why is that a contradiction to being undefined behaviour?
C vs. C++ vs. ...
Posted Jul 4, 2012 18:30 UTC (Wed) by jwakely (subscriber, #60262)
[Link]
1) I never claimed it had to work, my point is that extern "C" does not mean "cannot throw".
2) It doesn't _have_ to work, but it can work (which would make it closer to implementation-defined or conditionally-supported, not undefined) and does with (at least) GCC, Clang and Solaris CC. There's even a cross-platform standard describing it. For a nice overview of the "personalities" that are used to support mixed-language exceptions to propagate through call frames using different languages see http://llvm.org/docs/ExceptionHandling.html