Po Lu writes: > Arsen Arsenović 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? I agree that it is unnecessary to support them. The context that I took to understand is specifically wanting to support C++ modules. If that is not the case, then -fexceptions is not worth enabling, indeed. -- Arsen Arsenović