Re: Merging feature/android

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> -fexceptions is useful if it is possible to get a call stack which
> invokes C++ through a C function through a C++ function, for instance,
> if the comparator of a qsort could throw.  This provides the user of a
> given C API to gracefully handle thrown errors.  Alternatively, it also
> allows the C API developers to (mostly) gracefully clean up when a C++
> exception remains uncaught.  This is why libc is compiled with
> -fexceptions for instance.
>
> __attribute__((cleanup)) will run cleanups during stack unwinding:

Only if you build Emacs with -fexceptions.

> ‘cleanup (CLEANUP_FUNCTION)’
>      The ‘cleanup’ attribute runs a function when the variable goes out
>      of scope.  This attribute can only be applied to auto function
>      scope variables; it may not be applied to parameters or variables
>      with static storage duration.  The function must take one
>      parameter, a pointer to a type compatible with the variable.  The
>      return value of the function (if any) is ignored.
>
>      If ‘-fexceptions’ is enabled, then CLEANUP_FUNCTION is run during
>      the stack unwinding that happens during the processing of the
>      exception.  Note that the ‘cleanup’ attribute does not allow the
>      exception to be caught, only to perform an action.  It is undefined
>      what happens if CLEANUP_FUNCTION does not return normally.
>
> IMO, the price of exceptions is overblown, so it could be worthwhile
> adopting this, if I understand the context right.

If a C++ exception is thrown inside a module function, then we should
IMO just let everything blow up.  How are they different from any other
kind of unexpected error in a dynamic module, such as for instance an
arithmetic trap, memory access error, or perhaps a Pascal exception?