realloc 0.1.1

A re-implementation of various ::alloc features
Documentation
  • Coverage
  • 100%
    64 out of 64 items documented1 out of 20 items with examples
  • Size
  • Source code size: 77.96 kB This is the summed size of all the files inside the crates.io package for this release.
  • Documentation size: 2.46 MB This is the summed size of all files generated by rustdoc for all configured targets
  • Ø build duration
  • this release: 10s Average build duration of successful builds.
  • all releases: 11s Average build duration of successful builds in releases after 2024-10-23.
  • Links
  • Repository
  • crates.io
  • Dependencies
  • Versions
  • Owners
  • Kyllingene

A re-imagining of allocation in Rust from the ground-up. Fully no_std and portable.

Everything is built on top of the [Allocator] trait (and [AllocatorExt]); the goal is to make allocation itself 100% safe. To that end, it introduces the [Alloc] abstraction to ensure no allocation is double-freed or freed in the wrong allocator.

A secondary (but still very important) goal is genericity. For this, all built-in allocations are fully generic over what allocator they use, as well as the strategy used to handle allocation failures.

The feature flag global enables the global allocator framework, which allows one to set an allocator for all collections to use by default.

The crate comes with built-in system allocators for Linux (via aligned_alloc) and Windows (_aligned_malloc), but only with feature platform enabled. (with both global and platform, the global allocator is initially the platform allocator)

A number of containers are defined in the crate (at the time of writing, [Box] and [Vec], to varying degrees of completeness). Note that Box is somewhat different to std::box::Box, due to the lack of compiler magic.

It also provides certain portable predefined allocators (currently [Arena] and [Array]). Of course, you can always define your own, and use them just the same.

Note that while the whole crate is no_std, and aside from platform is totally portable, it does make use of core::sync::atomic. If your desired platform doesn't support atomics at all, this crate will not work.