Re: [Tinycc-devel] crash when function that is called from tcc compiled dynamic library, throws exception

[Stephan Beal]

On Tue, Sep 15, 2015 at 1:21 PM, Jacek Wielemborek <address@hidden> 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