[PATCH] D51317: Handle BumpPtrAllocator::Allocate(0) without undefined behavior

Brent Royal-Gordon via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 5 03:17:15 PDT 2018


> On Sep 4, 2018, at 3:04 AM, Chandler Carruth via Phabricator <reviews at reviews.llvm.org> wrote:
> 
> FWIW, just because a lot of code hits the assert for non-zero size does not (to me) mean that isn't the correct approach.
> 
> I actually think that the API is better if allocating zero size is disallowed. I think making clients think about how it makes sense in *their* case to handle this degenerate case is better than trying to do something inside the allocator. I think we'll constantly make one set of users of the API or the other unhappy: either we allocate when we shouldn't to avoid returning a nullptr, or we make clients deal with a potentially-null return.

I understand that perspective, but I'm not really sure there's much "dealing" for clients to do. With the patch in place, the allocator returns null only if it allocates zero bytes, meaning there's no space reserved for that pointer and it should never be dereferenced anyway. The best way to handle a zero-byte allocation is probably to leave null whatever variable you would have otherwise set to point to the buffer—and that's exactly what would happen with this patch. So I don't think the null solution will make a set fo users unhappy unless they're being pedantic.

(And as a practical matter, as a first-time contributor I'm just not sure what steps I should take before making a breaking change of that magnitude. I assume you'd want to give Clang and other projects a heads-up, but I have no idea who should be involved.)

-- 
Brent Royal-Gordon
Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180905/fed8f7e7/attachment.html>


More information about the llvm-commits mailing list