[libcxx-commits] [PATCH] D150610: [libc++] Make sure `operator new` never returns nullptr, even under -fno-exceptions

[Jonathan Wakely via Phabricator via libcxx-commits]

jwakely added a comment.

In D150610#4343811 <https://reviews.llvm.org/D150610#4343811>, @ldionne wrote:

> Also, @jwakely I'd like to know how you feel about the fact that `new(size_t, nothrow_t)` aborts instead of returning `nullptr` when the shared library is built using `-fno-exceptions`. Is that a concious choice you made in libstdc++, and if so, what's the rationale?

I consider it to be a bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477 (which I first noted at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68210#c2 in 2016, but still haven't fixed).
It's not a conscious choice, just how it works because nobody has implemented anything better yet.

> Naively, I would say this surely seems a bit surprising, but it seems to be the only way to satisfy the Standard's requirements under `-fno-exceptions` (since the `nothrow_t` version must call the throwing version).

See the bug report above for another approach, which I've not had time to finish working on (and which won't work on all targets). It detects whether the program has replaced `operator new(size_t)` and if it _hasn't_, then we can make the `nothrow_t` version just return a null pointer directly. If the user has replaced `operator new(size_t)` then they'd better replace the `nothrow_t` one as well if they want to use `-fno-exceptions`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150610/new/

https://reviews.llvm.org/D150610