Hacker News new | ask | show | jobs
by masklinn 1187 days ago
It’s not a invariant is the thing.

Transient allocators doing little to nothing on free so you can do all the work at once at end of scope is often what you want, if anything a bump allocator freeing its tip is an optimisation.

The issue is not that it behaves this way, it’s that it’s not obvious at first glance that this is a bump allocator.

2 comments

> a bump allocator freeing its tip is an optimisation

That's kinda my point? free is there and does something, but also silently does nothing if you violate a fairly subtle invariant. Kinda the definition of "error-prone", and the whole blog post seems to prove it, as the leak was essentially caused by the author not realizing that free was silently doing nothing. I understand why bump-allocators exist, I'm just saying this particular one's API has quite the footgun.

> That's kinda my point?

It’s the exact opposite of your point.

> free is there and does something, but also silently does nothing if you violate a fairly subtle invariant.

Again, not an invariant.

> the leak was essentially caused by the author not realizing that free was silently doing nothing

The leak was caused by the author not knowing this is a bump allocator because that was not clear from the naming (and the documentation is essentially non-existent).

> I'm just saying this particular one's API has quite the footgun.

It’s not the API that’s a footgun, it follows the standard allocator API so it can be used wherever an allocator is expected. If it did not, its usage scope would be extremely limited as you'd only be able to use it for bespoke allocations, and wouldn't be able to use it for allocating e.g. arrays or sets or maps.

No, there are contexts where you exactly want this behaviour is what poster above wanted to say, and I agree. But it needs to be well documented.
> invariant

There is absolutely no such invariant here that allocations must be freed in the reverse order that they were allocated in. This was never a part of the contract.

> this particular one's API has quite the footgun

Agreed, however.

You are entirely correct. If anything, if I were the OP the title of the blog would be "Naming matters - The curious case of ..."

https://docs.rs/bumpalo/latest/bumpalo/