On Tue, Sep 15, 2015 at 1:21 PM, Jacek Wielemborek <[email protected]> wrote:
> A crash isn't good behavior anyway. There's the risk that it's a memory
> error leading to a security vulnerability - and compiling source code
> can be a real attack vector.
>
When a C++ exception passes through C code it bypasses the return of all
the C functions (resp. non-C++-functions) between the throw point and the
catch (if any). There is no possibility, generically speaking, for a clean
shutdown. A crash is the best one can do, in the generic case. _Not_
crashing means leaving an arbitrary amount of leaked resources open in the
app, all in an undefined state, because the functions which initialized
them did not get to finish running to completion:
A most trivial example:
int foo(){
void * x = malloc(...);
initialize_x( x );
funcWhichThrows( x );
free( x );
return 0;
}
that free() is never reached when an exception is thrown. That's an
absolutely trivial case - many are not so trivial, and may leave
file/network/X11/etc resources open or in an undefined state (e.g. a db
handle might be left with an opened transaction).
A crash is the only sane solution.
Herb Sutter (i believe it was) wrote a long article in the 90's about why
it is a truly bad idea to allow exceptions to pass through dynamic module
boundaries, but AFAIK it's only available in paper form. Short form:
undefined behaviour.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
