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

Custom allocators vs Box noalias #122

Open
RalfJung opened this issue Mar 5, 2024 · 0 comments
Open

Custom allocators vs Box noalias #122

RalfJung opened this issue Mar 5, 2024 · 0 comments

Comments

@RalfJung
Copy link
Member

RalfJung commented Mar 5, 2024

rust-lang/miri#3341 provides an interesting example of a custom per-Box allocator that is incompatible with having noalias at the Box pointer. The problem is that the allocator uses offsets from the data pointer passed to deallocate to access allocator state, but this means when two Box<T, &MyAlloc> are passed to a function and dropped in that function, then the allocator state is accessed through these two separate data pointers, which are both noalias, so that's an aliasing violation. My impression is that allocators are allowed to do that kind of stuff, so the noalias has to go when a Box uses a custom allocator -- but that should be clarified.

For global allocators, deallocation is a compiler-understood "magic" operation, so there's a chance we can make this work. It has to be magic anyway since allocation is already magic. But custom per-Box allocators are just regular function calls so there's no such magic. (I guess an alternative to dropping noalias would be to make them more magic. Not sure if anyone wants that.)

Opening this here so this is answered definitely before stabilization. In particular there should be a proper decision on whether such code should be UB or not.

@RalfJung RalfJung changed the title Custom allocators in Box are incompatible with Box noalias Custom allocators vs Box noalias Mar 6, 2024
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

1 participant