| |||||||||||||
C vs. C++ vs. ...C vs. C++ vs. ...Posted Jul 4, 2012 12:52 UTC (Wed) by jwakely (subscriber, #60262)In reply to: C vs. C++ vs. ... by nix Parent article: Why learn C? (O'Reilly Radar)
marked as extern "C" or something similar to indicate the impossibility of exceptions emanating from those points extern "C" doesn't mean any such thing.
#include <stdio.h>
struct E { };
extern "C" void f();
int main()
{
try {
f();
} catch (const E&) {
puts("Caught");
}
}
extern "C" void f() { throw E(); }
(Log in to post comments)
C vs. C++ vs. ... Posted Jul 4, 2012 13:37 UTC (Wed) by andresfreund (subscriber, #69562) [Link]
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.
C vs. C++ vs. ... 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
C vs. C++ vs. ... Posted Jul 4, 2012 15:08 UTC (Wed) by nix (subscriber, #2304) [Link]
Oooh. Interesting. Given that 99% of C libraries are not compiled with -fexceptions and do not specify anything nothrow-related in their prototypes (of course not, they're C), this suggests that G++ is introducing a very large number of unnecessary abnormal edges for exceptions potentially raised in calls to such functions that cannot possibly ever be thrown. I wonder how much this is impairing optimization?
C vs. C++ vs. ... Posted Jul 4, 2012 15:51 UTC (Wed) by scottt (subscriber, #5028) [Link] > Given that 99% of C libraries are not compiled with -fexceptionsNote that Red Hat and Fedora has been building the whole distro with -fexceptions for years: rpmbuild --showrc | grep cflags -14: __global_cflags -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions <...>I suspect other distros do the same.
C vs. C++ vs. ... Posted Jul 4, 2012 18:43 UTC (Wed) by jwakely (subscriber, #60262) [Link]
Doesn't the stack have to be unwound similarly for thread cancellation?
The C frames don't need to do any cleanup (no destructors) and should just let the exception propagate unhindered, until it reaches a frame with the right C++ personality to handle it.
I might be completely wrong, but I don't see any obvious reasons the generated code should be different.
|
|||||||||||||