On 12/17/2016 05:24 PM, Jakub Jelinek wrote: > On Sat, Dec 17, 2016 at 11:17:25AM -0500, Frank Ch. Eigler wrote: >> Pedro Alves <pal...@redhat.com> writes: >> >>> [...] >>> malloc will fail, new will throw bad_alloc, and GCC will abort and >>> maybe generate a core dump, instead of gracefully printing >>> something like: >>> cc1: out of memory allocating NNNNNNNN bytes ... >>> and existing with error status. >> >> Consider having the main() function catch bad_alloc etc. and print >> prettier error messages than the builtin uncaught-exception aborter? > > GCC is built with -fno-exceptions -fno-rtti, so no catching...
Right. Let me expand on that: - GCC wants to build with -fno-exceptions, so that can't work. - Even if GCC was built with -fexceptions, I'd suspect that there'll be GCC code that could throw an exception that would try to cross some non-C++/C code that is not built with -fexceptions, via callbacks. (Think qsort, but also all the C libraries in the repo). That problem tends to be missed on x86_64 GNU/Linux, since the ABI mandates -fexceptions. But it's a real problem on other systems. That's fixable, but if you're not using exceptions for anything else, you'll usually only notice it when things are already pretty down south. - You'd have to do this in the entry point of all threads. Not sure GCC ever spins threads today, but I'd avoid a design that prevents it, because who knows what support and run time libraries do internally. - Lastly, even if the technical details above were all resolved, I'd still recommend against the top level catch(bad_alloc) approach, since by the time the exception is caught, you've lost context of where the exception was originally thrown, i.e., where the bad allocation is coming from. The operator new approach allows for example having gcc automatically print its own backtrace for bug reports, with e.g., glibc's backtrace() or libbacktrace or some such. Thanks, Pedro Alves
