> Letting an exception thrown from C++ code cross into C code will be > EXTREMELY ugly. The C++-to-C boundaries *must* have unconditional catch > blocks to convert thrown exceptions into appropriate error codes, even > if the C++ code in question never knowingly throws an exception. C++ may > throw std::bad_alloc on failure of operator new(), among other things, > so the user must _always_ have an unconditional catch. Letting an > exception propagate out to the C-based Pg backend is rather likely to > result in a backend crash. Right, but I don't think that this differs from the general C++ case. Allowing exceptions to propagate across module boundaries was always a bad idea, as was managing memory across module boundaries. Aside from being very messy, they had to have exactly compatible runtimes and so on. > If the C++ libraries you are using will put up with it, compile your C++ > code with -fno-exceptions to make your life much, much easier, as you > can avoid worrying about this entirely. OTOH, you must then check for > NULL return from operator new(). That's the pre-standard behaviour of operator new(), and operator new() continues to behave that way on some platforms, typically embedded systems. > If you can't do that: My usual rule is that any "extern C" function > *must* have an unconditional catch. I also require that any function > that may be passed as a function pointer to C code must be "extern C" > and thus must obey the previous rule, so that covers function pointers > and dlopen()ed access to functions. > Seems reasonable, and not overly difficult. > > Similarly, calling Pg code that may use Pg's error handling from within > C++ is unsafe. It should be OK if you know for absolute certain that the > C++ call tree in question only has plain-old-data (POD) structs and > simple variables on the stack, but even then it requires caution. C++ > code that uses Pg calls can't do anything it couldn't do if you were > using 'goto' and labels in each involved function, but additionally has > to worry about returning and passing non-POD objects between functions > in a call chain by value, as a longjmp may result in dtors not being > properly called. Really? That seems like an *incredibly* arduous requirement. Intuitively, I find it difficult to believe. After all, even though using longjmp in C++ code is a fast track to undefined behaviour, I would have imagined that doing so in an isolated C module with a well defined interface, called from C++ would be safe. I would have imagined that ultimately, the call to the Pg C function must return, and therefore cannot affect stack unwinding within the C++ part of the program. To invoke a reductio ad absurdum argument, if this were the case, calling C functions from C++ would be widely considered a dangerous thing to do, which it is not. After all, setjmp()/longjmp() are part of the C standard library...in general, it's difficult to know whether or not a third party module may use them. Have you ever seen a C library marked as C++ safe or C++ unsafe? No, me neither. Perhaps I'm missing something though...does the error handling portion of the pg code potentially need a hook into the C++ code, from where the longjmp() must be performed? I don't know what you mean by "a call chain by value". The bottom line is that *I think* you're fine as long as you don't do setjmp()/longjmp() from within C++. You may even be okay if you just do setjmp() from within C++. The longjmp() will hopefully only affect stack unwinding before we get down to the C++ part of the stack, where that matters. -- Regards, Peter Geoghegan -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
