[libc-commits] [PATCH] D139584: [libc] Add custom operator new to handle allocation failures gracefully.

[Siva Chandra via Phabricator via libc-commits]

sivachandra added inline comments.


================
Comment at: libc/src/string/allocating_string_utils.h:27
+  AllocChecker ac;
+  char *newstr = new (&ac) char[len];
+  if (!ac)
----------------
tschuett wrote:
> lntue wrote:
> > Does it mean that our `strdup` will always return aligned strings?
> Would in this case a malloc returning a result or error type easier to understand and safer?
> Does it mean that our `strdup` will always return aligned strings?

This is should call the non-aligning `operator new`. Why do you think it would always calls the aligning `operator new`?


================
Comment at: libc/src/string/allocating_string_utils.h:27
+  AllocChecker ac;
+  char *newstr = new (&ac) char[len];
+  if (!ac)
----------------
sivachandra wrote:
> tschuett wrote:
> > lntue wrote:
> > > Does it mean that our `strdup` will always return aligned strings?
> > Would in this case a malloc returning a result or error type easier to understand and safer?
> > Does it mean that our `strdup` will always return aligned strings?
> 
> This is should call the non-aligning `operator new`. Why do you think it would always calls the aligning `operator new`?
> Would in this case a malloc returning a result or error type easier to understand and safer?

Couple of points:

1. We want the libc source code to look as much as possible like a normal modern C++ library.
2. Using `new`/`delete` for allocation/deallocation has the added benefit that compilers will synthesize constructor/destructor calls appropriately. It is not relevant here I would think, but uniformity helps improve readability and keeps coding guidlines/principles simple.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139584