>>5
A brief review of libstdc++ seems to indicate that we are set up to handle -fno-exceptions by calling abort or terminate if an exceptional condition is generated while in the -fno-exceptions mode. This includes operator new, but requires a recompile of libstdc ++ to get the behavior. I.e. -fno-exceptions changes the behavior of the compiled binary libstdc++. This isn't surprising, and indeed it is what I would expect.
So for
http://gcc.gnu.org/ml/gcc/2004-10/msg00099.html, my knee-jerk reaction is to say "recompile libstdc++" with that setting if you need it to not thrown an exception". That being said, my response is probably not what the customer wanted either. He wanted op new to return 0 on failure, not abort. In general it would be nice to give the customer the ability to customize error handling when exceptions are turned off. For example instead of calling abort() in an exceptional situation we might instead call a weak-linked __gcc_handle_error(const char* msg). The customer then might override this function, inspect the message, and do something that makes sense for them. The default implementation could just call abort(), maybe after printing out the msg. This still requires a recompile of libstdc++, but at least it gives the customer another option. Here's how it might look:
operator new (std::size_t sz) throw (std::bad_alloc)
{
...
if (! handler)
#ifdef __EXCEPTIONS
throw bad_alloc();
#else
std::__gcc_handle_error("bad_alloc");
#endif
...
}