14 releases

0.2.5 Feb 17, 2024
0.2.4 Oct 21, 2022
0.2.3 May 13, 2021
0.2.2 Jan 31, 2021
0.0.7 Jul 30, 2019

#43 in Memory management

Download history 5433/week @ 2024-07-04 6358/week @ 2024-07-11 5975/week @ 2024-07-18 5792/week @ 2024-07-25 3647/week @ 2024-08-01 3422/week @ 2024-08-08 4287/week @ 2024-08-15 5219/week @ 2024-08-22 4960/week @ 2024-08-29 4548/week @ 2024-09-05 5051/week @ 2024-09-12 4484/week @ 2024-09-19 4584/week @ 2024-09-26 2945/week @ 2024-10-03 3492/week @ 2024-10-10 5212/week @ 2024-10-17

17,361 downloads per month
Used in 12 crates

MIT OR Apache-2.0 OR Zlib

115KB
1K SLoC

static-alloc

Crates.io Status Docs.rs Status License CI Status

General purpose global allocator(s) with static, inline storage.

Goal and Target Platform

Provides an allocator for extremely resource constrained environments where the only memory guaranteed is your program's image in memory as provided by the loader. Possible use cases are OS-less development, embedded, bootloaders (even stage0/1).

The primary goals are similar to the standard library simplicity, and correctness, and minimal assumptions.

Usage

As a global allocator for alloc with some safe allocation extensions:

use static_alloc::Bump;

#[global_allocator]
static A: Bump<[u8; 1 << 16]> = Bump::uninit();

fn main() {
    // Vec occupying `1 << 7` bytes
    let v = vec![0xdeadbeef_u32; 32];

    // … or allocate values directly.
    let buffer: &mut [u32; 32] = A.leak([0; 32])
        .unwrap();
    buffer.copy_from_slice(&v);
}

You can also use it as a local allocator creating dynamic values on the stack. In this case you might want to be more conservative with resource usage so as not to blow the stack. The benefit is even larger using it together with without-alloc which provides high-level data structures that you are used to from alloc.

use static_alloc::Bump;

fn main() {
    for _ in 0..100 {
        let local: Bump<[u8; 32]> = Bump::uninit();
        let temp_buffer = local.leak([0; 32]);
	// Resources are cleaned up.
    }
}

Contributing

PRs introducing more tests or documentation are very welcome! Whatever else submitted should have simplicity and composability in mind, ideas that can not be put into a draft form are likely too complex or not focussed enough. PRs should be extremely reluctant with introducing new dependencies and should contain no non-optional dependency.

Please open issues with drafts only, feature requests and 'help' issues will be closed (if you are lucky with a final comment). Stability trumps growth. I simply can not make any longterm commitment outside my intrinsic motiviation towards this project. Hence, I favour a highly usable core over a large interface that is only somewhat usable.

Additional

This project is licensed under Zlib OR Apache-2.0 OR MIT. You may alternatively choose the Unlicense instead in which case the copyright headers signify the parts dedicated to the public domain to the fullest possible extent instead.

Dependencies