[PATCH] D51317: Keep BumpPtrAllocator::Allocate(0) from returning nullptr

Hans Wennborg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 30 01:15:39 PDT 2018


hans added a comment.

In https://reviews.llvm.org/D51317#1216483, @jordan_rose wrote:

> If we do take this answer, we should *still* go to all clients and see if a zero-length check makes sense. "Copying" an empty string or empty array should definitely not result in an allocation.


In that case, should we just assert about it in the allocator?

In https://reviews.llvm.org/D51317#1218541, @brentdax wrote:

> If we end up in a place where you’d still want to avoid empty allocations, then I think we should go back to the previous implementation. Current clients are already receiving duplicate addresses, so this won’t cause any new bugs. We can clearly document the behavior.
>
> An alternative might be to return deliberately invalid addresses, for instance by returning addresses from a guard page. That seems overengineered, though—I think duplicate addresses are fine.


I think we'd have to drop the LLVM_ATTRIBUTE_RETURNS_NOALIAS attribute though, and the behaviour would differ from malloc and operator new, which both guarantee unique return address (and it's implementation defined whether they allow zero-sized allocs). I don't know how much that matters, though.


Repository:
  rL LLVM

https://reviews.llvm.org/D51317





More information about the llvm-commits mailing list