std-freestanding-alloc-libc

The replaceable allocation functions for std-freestanding, forwarded to the target's C library.

[dependencies]
std-freestanding = { version = "0.3.1", features = ["alloc-libc"] }

⚠️ 0.3.1 and not 0.3.0. The [feature-deps] entry in 0.3.0 named a version selector the resolver does not have, so the feature activated and its implementation could not be fetched. A feature whose implementation cannot be fetched is a feature that does not exist.

What this is for

A freestanding target has no compiled libc++, so operator new does not exist, and std::vector fails at the link naming a mangled symbol. This package supplies the twelve overloads over malloc, free and aligned_alloc.

It is the shorter path whenever the target has a C library: a board package that already links -lc has an allocator, and routing it through an abstraction buys nothing there.

Why the implementation is a package rather than part of the subset

operator new is a whole-program singleton. The subset declares a feature that requires the freestanding-allocator capability; implementations provide it; the resolver binds exactly one and reports two by name, before the build rather than as a duplicate definition during the link.

Declaring nothing, and why

⚠️ This package has no dependency and can have none. The C library is a property of the target — mcpp resolves it from the target's own row exactly as it resolves the compiler — so there is nothing in the dependency graph to name.

The consequence is that it links only where a C library is present. On the zero-libc tier ([target.<triple>].sysroot = "") it fails naming malloc, which is the truthful message: there is no allocator to forward to. A project in that arrangement wants std-freestanding-alloc-kal with a backend of its own, or its own twelve overloads.

Choosing the other one

std-freestanding-alloc-kal forwards to openkal instead, which is what a project wants when the same sources must also build for a target whose environment is not a C library.