David Vandevoorde wrote:
The __cxa_exception by reference (I've called it "dependent exception" in my new writeup) could indeed be made to look like that, but that's not the real problem. The real problem is code using the old library catching a primary exception to which exception_ptrs refer. The old support library might disrespect the reference counting necessary to keep the object alive, and would delete it, leaving the exception_ptrs dangling. (I say "might", because if the library uses _Unwind_DeleteException to delete native exceptions, like G++ does, the reference counting could be put there.) That said, this shouldn't be that much of a problem. Strictly speaking, G++ already doesn't allow cross-module throwing if a static support library is used. The reason is that in static links, there would be multiple emergency memory pools. An exception allocated in the emergency pool of one module and caught in a different module would then be incorrectly passed to free() for deletion, which would crash anyway. And that's with all code compiled with exactly the same compiler version.On May 27, 2008, at 4:39 AM, Sebastian Redl wrote:This might work. But *only* if all modules link to the support library dynamically, of course. If any of them links statically, it would keep the old implementation, which would wreak havoc.What sort of failure modes would we expect. Could the "__cxa_exception by reference" be made to look like std::bad_exception to an old runtime support library?
FWIW, I've contacted Peter Dimov about this issue, and he seems agreeable to prohibit rethrowing an exception captured with current_exception() using "throw;" (until it has been rethrown with rethrow_exception, at which point it can be caught/rethrown the usual way).I don't see a particular reason to prohibit this. At least, I don't foresee any implementation problems that would be solved this way. (Put it this way: of all the crazy things you can do with exception_ptrs - and you can do very crazy things - this is on the mild side.)
Sebastian