[libc-commits] [PATCH] D157653: [libc][WIP] move realloc into alloc_checker

Siva Chandra via Phabricator via libc-commits libc-commits at lists.llvm.org
Fri Aug 11 15:37:13 PDT 2023


sivachandra added a comment.

In D157653#4581526 <https://reviews.llvm.org/D157653#4581526>, @mcgrathr wrote:

> In D157653#4580990 <https://reviews.llvm.org/D157653#4580990>, @sivachandra wrote:
>
>> Should we restrict this to trivially destructible types?
>
> realloc should be restricted to trivially copyable types, because realloc is going to copy them byte-by-byte for the existing elements in the array.

Ah yes, trivially copyable also.

> It doesn't really need to be restricted to trivially destructible types, because eventual `delete[]` should still work as it would with any array from `new[]`.

Discussing for academic knowledge:
If `realloc` allocates a whole new array, existing objects are copied over and so we need them to be trivially copyable. But, since the old array is free-d, we will need the trivially destructible property also?
Further, after the call to the reallocating `new`, wouldn't the compiler try to initialize the copied over objects also? If yes, we will need the trivially constructible property also?

> Likewise, if we had a front-end for the trimming case, then that could explicitly call destructors on the tail elements if need be.

By front-end, do you mean the caller of the reallocating `new`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157653



More information about the libc-commits mailing list