(If this question is better suited to the internals forum, I would be happy to move it. It seems like it's on the fence as I write it.)
For both embedded development and testing reasons, I would like to implement a Global Allocator for a
no_std program with its own backing store.
When I looked at Rust allocator crates, thinking that someone surely has done this already, all of them simply rely on libc's
malloc, and have no way to specify a different way to get allocation backing. They are focused on the algorithm for the allocations: zone-based, record-based, metadata, fragmentation, etc.
This old thread helped make clear what my real problem was: I didn't need an allocator, but my own version of
free written in Rust to replace the libc's.
As an example, if I were on an embedded device, I would want every heap allocation to go into a static 16k array called
the_heap, which would be created via a linker symbol. Such a
no_std platform has no libc involved.
Given that Rust's allocators are alignment aware, and the platforms I plan to use this on vary between 32 and 64-bit, there is one important thing mentioned in the POSIX documentation for
malloc that I am trying to work out:
The pointer returned if the allocation succeeds shall be suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object in the space allocated (until the space is explicitly freed or reallocated).
This brings up several questions:
- How would I know what that is for a given platform? (I assume this is not easy.)
- Could I just pick a number -- say, 16 bytes -- and always be correct at the expense of wasted space?
- Are there cases where Rust communicates over-specified alignments (i.e. user-specified as higher than the required alignment of the base type) in strange ways, like
callocN slots instead of
malloc4 * n bytes?
Or, has someone already solved my problem some other clever way?