Subject
allocator-api2 is a polyfill that mirrors Rust's unstable
allocator_api feature (the Allocator trait plus Global / System
allocators and allocator-parameterised Box, Vec, RawVec, and
supporting iterators) on stable Rust. It is intended for library authors
who want to write allocator-aware code without requiring nightly
toolchains. The README states the code is "mostly verbatim copy from
rust repository", and the published source confirms this: Box, Vec,
and RawVec are near line-for-line copies of their counterparts in
rust-lang/rust's alloc crate.
Methodology
The published crate contents were compared against the upstream Git
repository at the commit recorded in .cargo_vcs_info.json using
diff. The only differences were Cargo's standard Cargo.toml
normalisation, the addition of Cargo.toml.orig and
.cargo_vcs_info.json, the removal of the tests/ workspace member,
and line-ending differences (CRLF in the published archive vs LF in
the VCS tree); after stripping carriage returns, source files matched
byte-for-byte. The repository's git remote
(https://github.com/zakarumych/allocator-api2) matches the
[package].repository field in Cargo.toml.
All source files under contents/src/ (~8 kLoC, primarily boxed.rs
2272 lines, vec/mod.rs 3232 lines, raw_vec.rs 642 lines,
alloc/mod.rs 416 lines) were read. Each unsafe block in the
alloc/Global/System modules and the high-traffic helpers
(Box::into_inner, Box::leak, Box::from_raw_in, RawVec::grow_*,
Vec::set_len, Vec::truncate, Drain::drop, IntoIter
construction/drop, SliceExt::to_vec_in's panic-safety guard) was
inspected against the SAFETY comments and the documented Allocator
contract.
The published archive was checked for binaries, build scripts, and
proc macros via filesystem search and inspection of Cargo.toml. The
full crate source was grepped for std::{env,fs,net,process,thread, io,sync} and for extern "C" to confirm the absence of I/O, FFI, and
runtime side effects. The VCS workspace tests/ member was inspected.
The test suite was not run, as the published crate ships no tests of
its own (see FINDING-1).
Tools: openvet 0.6.0 for workspace and audit data management;
diff (Apple) for the byte-level comparison; git (2.51) for the
upstream checkout; file/tr for line-ending inspection;
grep/ripgrep for capability surveys.
Results
The comparison between the published crate contents and the upstream
Git repository shows that, after CRLF normalisation, every source
file matches the recorded commit byte-for-byte; manifest differences
are limited to cargo's standard normalisation.
The crate ships no binary artefacts, justifying has-binaries. There
is no build.rs, Cargo.toml sets build = false, and the crate is
not a proc-macro library, justifying has-build-exec and
has-install-exec. The crate performs no I/O of any kind:
std::io::{Read,Write,Seek,BufRead} appears only as trait
forwarding impls on Box<T, A> (delegating to the inner type) and
io::Write for Vec<u8, A> (appending bytes to the vector, matching
the rustc stdlib impl). There is no use of std::{env,fs,net, process,thread,sync} and no FFI. This justifies uses-network,
uses-filesystem, uses-environment, uses-exec, uses-concurrency,
uses-crypto, uses-jit, and uses-interpreter. No cryptographic,
parser, interpreter, JIT, protocol, algorithm, or concurrency
implementation is present, justifying impl-crypto, impl-parser,
impl-interpreter, impl-jit, impl-protocol, impl-algorithm, and
impl-concurrency.
The crate implements its own Box, Vec, RawVec, Unique, and
IntoIter / Drain / Splice types on stable Rust, justifying
impl-datastructure; these implementations contain extensive unsafe
(raw-pointer arithmetic, ptr::drop_in_place, ptr::read, manual
deallocation, custom Send/Sync impls), justifying uses-unsafe.
The unsafe is concentrated where it is structurally required (the
data-structure internals and the allocator vtable), supporting
unsafe-minimal. Spot-checks against the documented Allocator
safety contract, the SAFETY comments at each unsafe block in
alloc/{mod,global,system}.rs, and the drop-safety guards in
Drain::drop, IntoIter::drop, and SliceExt::to_vec_in found no
unsoundness, supporting unsafe-safe, datastructure-impl-safe, and
datastructure-impl-correct. Capacity-overflow handling in
RawVec::grow_amortized / grow_exact (via Layout::array,
alloc_guard, and exponential doubling) matches the rustc stdlib
bounds for Vec, supporting datastructure-impl-bounds. Not every
unsafe block carries an explicit SAFETY comment (e.g. Box::drop,
Vec::clear, Vec::Drop), so unsafe-documented is asserted false.
The VCS history records a prior Fix the Box::into_inner's double free. (commits 5ba2f05 / dedb0ed) which would have been caught by a
unit test; the current Box::into_inner is the corrected version.
The published crate nonetheless ships zero tests of any kind:
Cargo.toml sets autotests = false, no tests/ directory is
shipped, and the VCS sibling workspace member allocator-api2-tests
contains only four generic helper functions and a tests! macro
intended for downstream allocator authors to exercise the trait
contract — no active #[test] invocations live in this repository.
This justifies has-unit-tests, has-integration-tests,
has-fuzz-tests, has-property-tests, unsafe-tested, and
datastructure-impl-tested all as false, and is recorded as finding
FINDING-1 (medium severity, given the surface area of unsafe).
Two additional low-severity quality findings were recorded:
FINDING-2 (the CHANGELOG.md contains only an ## [Unreleased]
placeholder despite many releases) and FINDING-3 (the published
archive has CRLF line endings while the VCS tree uses LF, with
boxed.rs even showing mixed CRLF+CR terminators, suggesting the
crate was packed in an environment with Git autocrlf enabled).
Neither affects correctness.
No malicious patterns, obfuscation, data exfiltration, time-bombs, or
target-specific payloads were found in the source. The code is a
transparent mirror of rustc's alloc crate, justifying is-benign.
Conclusion
allocator-api2 faithfully mirrors a small, well-understood subset
of rust-lang/rust's alloc crate to provide allocator-parameterised
data structures on stable Rust. The implementations are sound under
spot-checking and the crate has no build-time, install-time, or
runtime side effects beyond heap allocation. The principal concern is
the complete absence of a test suite for the crate's own Box /
Vec / RawVec (FINDING-1) despite the volume of unsafe;
downstream consumers relying on this crate as a Box / Vec
substitute should be aware that they are trusting the manual port
rather than a tested implementation.