Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow safety checks to compare the identity ofstd.mem.Allocators #23068

Open
190n opened this issue Mar 3, 2025 · 1 comment
Open

allow safety checks to compare the identity ofstd.mem.Allocators #23068

190n opened this issue Mar 3, 2025 · 1 comment

Comments

@190n
Copy link
Contributor

190n commented Mar 3, 2025

I'm working on getting Bun ready for Zig 0.14. We have an unmanaged container for borrowed subslices of strings, which uses one of the bits in the len to store whether it needs to be freed. In debug builds, CowSlice also stores an allocator so that, even though it is unmanaged, it can make sure you don't try to free it with the wrong allocator.

However, I understand that comparing the ptr field on an Allocator is unsound because some implementations set it to undefined. I see that this approach was maintained in #22691, instead of the counter-proposal to set unneeded ptr fields to null instead. We can of course compare only the vtable field instead, but that makes the safety check weaker, because it would consider two different instances of the same kind of allocator to be equal (e.g. two arena or fixed buffer allocators). I don't see a way to provide the strongest possible safety guarantees without sometimes comparing undefined pointers.

This safety check seems like it might be useful for std's unmanaged containers as well. Is this a use case that should be supported?

@rohlem
Copy link
Contributor

rohlem commented Mar 4, 2025

We can of course compare only the vtable field instead, but that makes the safety check weaker, because it would consider two different instances of the same kind of allocator to be equal (e.g. two arena or fixed buffer allocators).

It's a bit more effort, but if you have a registry of valid vtable pointers that maps to
information of whether the ptr field will be valid/sensible or not,
you can compare instances for those allocator types (identified by their vtable pointer) that do.

Allocators where ptr is unused, by their definition, don't really have the concept of an "instance".
(Though you could manually impose one by setting their ptr field to some fabricated pointer value, I guess.)

EDIT: At least that seems sensible to me in userland;
if such an approach is sanctioned by maintainers as well, we could standardize it in std as well.
(Although at that point we've re-introduced canonical comparability,
so I'd maybe question the decision against just making ptr optional.
It could be debug-only without changing the type,
but I personally think optionality changing between build modes would be acceptable too.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants