On 4 November 2015 at 01:55, Martin Sebor wrote: > On 11/03/2015 05:35 AM, Aurelio Remonda wrote: >> >> Currently, whenever operator new (std::nothrow) fails to allocate memory, >> it'll >> check if there is a new-handler function available. If there is, it'll >> call >> the handler and then try to allocate again. Otherwise, it'll return a null >> pointer. >> >> This retrying behavior may not always be desirable. If the handler cannot >> fix >> the memory allocation issue, we may end up being stuck in an infinite >> loop. >> Whereas returning nullptr may be a valid alternative to keep calling the >> new_handler. >> The workaround to end the loop, we would have to call >> std::set_new_handler(nullptr) >> from within the handler itself, which gets complicated if the handler has >> to be >> re-setted afterwards. >> >> This patch adds the new_nothrow_no_retry configuration flag, which, if >> enabled, >> will change the retrying behavior of operator new (std::nothrow) so that >> it only calls >> the handler once when it fails to allocate memory and the return nullptr. > > > The purpose of the loop is to give the new handler an opportunity > to free up enough memory to let the allocation succeed. Since the > handler doesn't get passed the size of the request it has no easy > way of determining how much memory to free. The loop lets it free > up increasingly more memory. If it can't free up any memory it is > expected/required to either indicate failure by throwing bad_alloc > or terminate the process. It's not allowed to return otherwise. > > Besides violating the requirement of the C++ standard, replacing > the loop with an if statement would disable that aspect of the > feature for the whole system (or for all processes that link with > the libstdc++ that was configured this way). It would effectively > be imposing a system-wide policy without providing a mechanism > for correctly written programs to opt out. In addition, as > a configuration option, it could not be easily tested. I would > therefore advise against making such a change.
I share your concerns, but I'm also sympathetic to the changes that the Taller Technologies team are trying to make, to allow libstdc++ to be more useful in exception-free systems. At the very least the patch to doc/xml/manual/configure.xml must document that this option enables behaviour that violates the standard and so produces a non-conforming implementation. It should probably also explain how to use the resulting implementation, so that users on embedded systems who might want to enable this know how to write a suitable new-handler.
