Description
This attribute is mandatory when using the alloc
crate without the std
crate. It is used like this:
#[alloc_error_handler]
fn foo(_: core::alloc::Layout) -> ! {
// …
}
Implementation PR: #52191
Blocking issues
- Adding #[track_caller] on #[alloc_error_handler] seems to cause undefined behavior #83430
- Who is responsible for preventing reentrancy issues through the allocator? unsafe-code-guidelines#506
- alloc_error_handler can be an
unsafe fn
which is then unsoundly invoked #134225 - The combination of alloc_error_handler and target_features_11 is unsound #134234
Original issue:
In a no_std
program or staticlib, linking to the alloc
crate may cause this error:
error: language item required, but not found: `oom`
This is fixed by providing the oom
lang item, which is is normally provided by the std
crate (where it calls a dynamically-settable hook #51245, then aborts). This is called by alloc::alloc::handle_alloc_error
(which is called by Vec
and others on memory allocation failure).
#![feature(lang_items)]
#[lang = "oom"]
extern fn foo(_: core::alloc::Layout) -> ! {
// example implementation based on libc
extern "C" { fn abort() -> !; }
unsafe { abort() }
}
However, defining a lang item is an unstable feature.
Possible solutions include:
- Add and stabilize a dedicated attribute similar to the
#[panic_implementation]
attribute:
#[alloc_error_handler]
fn foo(_: core::alloc::Layout) -> ! {
// …
}
The downside is that this is one more mandatory hoop to jump through for no_std
program that would have been fine with a default hook that aborts.
Movestd
’s dynamically-settable hook intoalloc
: Move OOM handling to liballoc and remove theoom
lang item #51607. The downside is some mandatory space overhead.
Metadata
Metadata
Assignees
Labels
Area: Custom and system allocatorsBlocker: Implemented in the nightly compiler and unstable.Category: An issue tracking the progress of sth. like the implementation of an RFCLibs issues that are tracked on the team's project board.Status: There are blocking design concerns.Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation.Relevant to the language team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.Working group: Embedded systemsThis PR / issue is in PFCP or FCP with a disposition to close it.The final comment period is finished for this PR / Issue.