3 ms·
It actually is possible to have decoupled allocation in a memory safe way. We have an open proposal for this in [0], for Vale. TL;DR: Have some bits in the mall
by verdagon 5y ago
It actually is possible to have decoupled allocation in a memory safe way. We have an open proposal for this in [0], for Vale. TL;DR: Have some bits in the malloc header which instruct the language on which deallocator function to use.
I've never used Odin, so I don't know whether/how they'd keep it safe.
[0]: https://docs.google.com/document/d/1243br9VVluZN0ZD9MVKSQMAwJbKO9ey9aJzmx6rnpAY https://docs.google.com/document/d/1243br9VVluZN0ZD9MVKSQMAw...
- ameliaquining 5y agoHmm. It seems the way this prevents use-after-free is by having the allocator's destructor check at runtime whether everything in it has already been dropped, and if not, abort the process. With bumpalo's default API (which seems to be designed to have the lowest possible per-allocation runtime overhead), that wouldn't work, because it deliberately doesn't keep track of whether the things in it have been dropped (and also because there's no header to store the bits in). On the other hand, if you required an API along the lines of bumpalo::boxed, and also were willing to add a bit more runtime overhead on top of that (for the tracking bits and the allocation count), then this could be done in Rust as a third-party library. Each executable that transitively depended on it would have to opt in with #[global_allocator], though. Also, I personally would rather have an API where the compiler makes sure I don't screw this up, than one where the runtime crashes my program if I do; this is generally a common sentiment in Rust, and points towards a bumpalo-style API.