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

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a comment.

In D150610#4345267 <https://reviews.llvm.org/D150610#4345267>, @jwakely wrote:

> 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.

Thanks for the additional context!

>> 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`.

That's interesting. I think we could do something similar. However, let's say we could do whatever we wanted and design from scratch, would you agree that it might make sense for `operator new(size_t)` to be equivalent to `operator new(size_t, nothrow_t)` when compiled with `-fno-exceptions`? I know the Standard doesn't formally acknowledge the existence of `-fno-exceptions`, but if we agreed that this is the desired behavior, we could perhaps relax the wording of `operator new` to make that implementation valid. WDYT?

I've spoken to some users in the embedded world and the consensus seems to be that having `operator new(size_t)` not return `nullptr` when it fails to allocate is problematic. Some have quite a bit of code already written where `operator new(size_t)` may return `nullptr` if it fails to allocate (which is a violation of the current spec technically).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150610