We have a third-party library that was written without multithreading or exception handling in mind. Our main executable is multithreaded and uses exceptions.
The th
The biggest and most obvious risk is resource leakage. If the library thinks its error handling strategy is to dive out of the nearest window there's alway a risk that throwing that exception isn't going to result in well organised release of memory and system resources.
However I notice you mention it doesn't allocate memory with malloc()
if that means you have to provide it with all its resources as buffers and the like then maybe by some miraculous accident it is safely unwindable!
If that fails all I can suggest is contact the supplier and persuade them that they should join the rest of us in 21st programming paradigms.
PS: Throwing an exception out of an atexit()
handler causes termination of C++ programs. So adding a throwing handler is not an option.
It's also not an option if some other library inserts an 'atexit()' handler after yours.
You can try leaving atexit()
handler with longjmp
. Though the behavior is undefined :)
The other way is to run lib in a separate process, bridged with any IPC. Harder, tedious, but safer.
Or, you can try to scan binary image and hook any exit()
invocations. I know about MS detours and mhook on windows. Though I know none on linux, unfortunately.
This is just an idea, but you could use a similar approach as i did when i needed to wrap memcpy
to use some different version, take a look at my answer here.
So you could build a replacement for the exit()
function that does nothing, or do some cleanup. It's just an idea and i have not tried it, but it could help you to solve your problem.