cargo / zerocopy / audit
cargo : zerocopy @ 0.8.48
PE Patrick Elsen signed 2026-05-27 published 2026-05-27

Claims

build-exec-deterministicbuild-exec-minimalbuild-exec-no-networkbuild-exec-no-write-outbuild-exec-safehas-binarieshas-build-exechas-fuzz-testshas-install-exechas-integration-testshas-property-testshas-unit-testsimpl-algorithmimpl-concurrencyimpl-cryptoimpl-datastructureimpl-interpreterimpl-jitimpl-parserimpl-protocolis-benignunsafe-documentedunsafe-minimalunsafe-safeunsafe-testeduses-concurrencyuses-cryptouses-environmentuses-execuses-filesystemuses-interpreteruses-jituses-networkuses-unsafe

Summary

Google-maintained foundational crate for safe transmutation between byte sequences and typed values. Pervasive unsafe is policy-comment-enforced (clippy::undocumented_unsafe_blocks) and tested under Miri (strict provenance + tree borrows), Kani formal proofs, and randomized layout in CI. One low-severity quality finding: 21 unsafe blocks marked FIXME(#429) are missing the per-block safety comment, tracked upstream.

Report

Subject

zerocopy is a Google-maintained Rust library that provides safe, zero-cost conversions between byte sequences and typed values. It is a no_std-by-default crate that exposes derivable marker and conversion traits (KnownLayout, Immutable, Unaligned, TryFromBytes, FromZeros, FromBytes, IntoBytes), conversion macros (transmute/transmute_ref/transmute_mut and their try_ variants), and byte-order-aware integer wrappers (U16, I16, U32, …) used for parsing wire formats. It is consumed extensively across the Rust ecosystem (hypervisors, cryptographic implementations, firmware) as a foundation for safer transmutation.

Methodology

The published crate (zerocopy-0.8.48.crate) was compared against the upstream Git repository at the commit recorded in .cargo_vcs_info.json (aa7c31671cb5ce509551edafa23c6865df83b180, "Release 0.8.48"); Cargo.toml.orig matched vcs/Cargo.toml byte-for-byte and the remaining differences were limited to cargo's standard normalisation (auto-generated Cargo.toml, omitted dotfiles excluded via exclude = [".*"], workspace-only siblings: testutil/, tools/, vendor/, zerocopy-derive/).

The crate's metadata (Cargo.toml, README.md, CHANGELOG.md, POLICIES.md, AGENTS.md, CONTRIBUTING.md) was read in full. The build script (build.rs, ~260 lines) was read in full and reasoned about. The crate's ~28k Rust source lines under src/ (lib.rs, impls.rs, layout.rs, macros.rs, byteorder.rs, ref.rs, split_at.rs, wrappers.rs, error.rs, byte_slice.rs, pointer/*, util/*) were surveyed for unsafe, FFI, network/filesystem/process/environment/concurrency usage, and representative unsafe impls were read in detail (src/impls.rs:19-200, src/byte_slice.rs:100-340, src/pointer/inner.rs:1-200, src/lib.rs:3560-3760). The 21 occurrences of FIXME(#429) were enumerated. The integration-test entry points (tests/codegen.rs, tests/include.rs, tests/ui.rs) were read; the CI workflow (.github/workflows/ci.yml) was inspected to confirm which test backends run.

Results

The published artefact matches the upstream VCS commit. The crate ships no binary artefacts (justifying has-binaries) and no installation-time hooks (cargo provides no install step; justifying has-install-exec).

The crate ships a build.rs whose presence justifies has-build-exec. As described in the file annotation, the script reads the crate-root Cargo.toml, parses the [package.metadata.build-rs] table to determine which --cfg no-zerocopy-… flags to emit, and invokes rustc --version via the documented RUSTC Cargo variable; no other files are read, no other processes are spawned, no network access occurs, output is restricted to cargo: directives and is a pure function of the rustc version and Cargo.toml. This justifies build-exec-safe, build-exec-deterministic, build-exec-no-network, build-exec-no-write-out, and build-exec-minimal.

The codebase was searched for network primitives (TcpStream, UdpSocket, reqwest, ureq), filesystem operations (std::fs, std::process, Command), and environment access (std::env); no occurrences appeared outside of doc-comment examples (justifying uses-network, uses-filesystem, uses-environment, and uses-exec). The crate is no_std by default, and even with std enabled it does not spawn threads, depend on an async runtime, or implement synchronisation primitives — the standard library's Atomic* types are referenced only to derive FromBytes/IntoBytes/TryFromBytes impls (src/impls.rs:455-565), so the crate does not itself use concurrency in the sense of uses-concurrency. No cryptographic operations, JIT, or embedded interpreters appear in the source (justifying uses-crypto, uses-jit, uses-interpreter).

zerocopy is fundamentally an unsafe-code library (~110 unsafe impls and ~107 unsafe { … } blocks across src/), justifying uses-unsafe. The library's existence — providing safe traits over operations that would otherwise require callers to write unsafe — supports unsafe-minimal: every unsafe block is in service of an abstraction that removes the need for unsafe in client code. Soundness is taken seriously: every non-test unsafe block is required by POLICIES.md to carry a safety comment that quotes the stable Rust documentation it relies on, with clippy::undocumented_unsafe_blocks enforcing the policy. Sampled blocks (e.g. src/impls.rs:19-200, src/pointer/inner.rs) follow this convention with stable-version-pinned doc.rust-lang.org links and verbatim quotations of the Reference. The CI matrix runs the test suite under Miri (with both -Zmiri-strict-provenance and -Zmiri-tree-borrows), under Kani for formal verification of layout/padding/byteorder routines (src/byte_slice.rs:372, src/layout.rs:1999-2176, src/util/mod.rs:153,237), under -Zrandomize-layout, and across multiple targets including big-endian aarch64 and AVR; combined with the ~114 #[test] functions, this justifies unsafe-tested. The combination of policy-enforced safety reasoning, Miri's UB detection, and Kani's formal proofs supports unsafe-safe.

One low-severity quality finding (FINDING-1) was recorded: 21 unsafe blocks bear FIXME(#429) markers and #[allow(clippy::undocumented_unsafe_blocks)] instead of the required safety comment. Their soundness is not in question — the invariants are documented elsewhere — but the gap prevents unsafe-documented from being asserted true. The gap is openly tracked upstream.

zerocopy does not implement cryptography, parsers of a wire format (it produces typed views into byte sequences supplied by the caller; the byte-order wrappers like U16<BigEndian> rearrange bytes but do not parse a grammar), interpreters, JITs, network protocols, novel data structures, or non-trivial algorithms, justifying impl-crypto, impl-parser, impl-interpreter, impl-jit, impl-protocol, impl-datastructure, impl-algorithm, and impl-concurrency.

The crate ships ~114 #[test] functions across src/, plus three integration-test entry points (tests/codegen.rs, tests/include.rs, tests/ui.rs) and a trybuild-driven UI test suite under tests/ui/, justifying has-unit-tests and has-integration-tests. No cargo-fuzz fuzz target or proptest/quickcheck property-test harness appears within this crate's source tree (justifying has-fuzz-tests and has-property-tests); the project relies instead on Kani formal proofs and Miri-driven randomised execution, which together provide stronger guarantees than typical property tests for the soundness-sensitive surface.

No code paths suggest data exfiltration, anti-analysis, time-bombs, network beacons, or typosquatting. Authorship, repository, and the upstream-matching VCS commit are consistent with a long-running Google-maintained project (the soundness regression history in CHANGELOG.md and the upstream-tracked #429 work indicate ongoing maintenance), justifying is-benign.

Conclusion

zerocopy 0.8.48 is a mature, security-focused Rust library whose engineering rigour materially exceeds that of typical crates: policy-enforced safety comments quoting stable Rust documentation, Miri runs under multiple aliasing models, Kani formal-verification proofs, randomized-layout testing, and cross-architecture CI. The single low-severity quality finding concerns 21 known-and-tracked undocumented unsafe blocks; their underlying soundness is not in dispute.

Findings(1)

FINDING-1 quality low

Undocumented unsafe blocks tracked in upstream #429

Twenty-one unsafe blocks across src/byte_slice.rs, src/impls.rs, src/lib.rs, src/pointer/inner.rs, src/util/macros.rs, src/util/macro_util.rs, and src/util/mod.rs are gated with #[allow(clippy::undocumented_unsafe_blocks)] and marked FIXME(#429) instead of carrying the safety comment required by POLICIES.md. Examples include the unmarked-trait unsafe impl ByteSlice for &[u8] blocks in src/byte_slice.rs and the alloc_zeroed / Box::from_raw pair in FromZeros::new_box_zeroed (src/lib.rs).

The soundness of these blocks does not appear to be in question — the invariants they rely on are documented elsewhere in the codebase — but the policy that justifies unsafe-documented requires each block to carry its own quoted-documentation safety comment. The project tracks the gap at https://github.com/google/zerocopy/issues/429 and the FIXME markers make the remediation queue auditable.

This prevents unsafe-documented from being asserted to true.

Annotations(7)

Cargo.toml

Cargo.toml, line 39-89

    "encoding",
    "no-std::no-alloc",
    "parsing",
    "rust-patterns",
]
license = "BSD-2-Clause OR Apache-2.0 OR MIT"
repository = "https://github.com/google/zerocopy"

[package.metadata.build-rs]
no-zerocopy-simd-x86-avx12-1-89-0 = "1.89.0"
no-zerocopy-core-error-1-81-0 = "1.81.0"
no-zerocopy-diagnostic-on-unimplemented-1-78-0 = "1.78.0"
no-zerocopy-generic-bounds-in-const-fn-1-61-0 = "1.61.0"
no-zerocopy-target-has-atomics-1-60-0 = "1.60.0"
no-zerocopy-aarch64-simd-1-59-0 = "1.59.0"
no-zerocopy-aarch64-simd-be-1-87-0 = "1.87.0"
no-zerocopy-panic-in-const-and-vec-try-reserve-1-57-0 = "1.57.0"

[package.metadata.ci]
pinned-stable = "1.93.1"
pinned-nightly = "nightly-2026-01-25"

[package.metadata.docs.rs]
all-features = true
rustdoc-args = [
    "--cfg",
    "doc_cfg",
    "--generate-link-to-definition",
    "--extend-css",
    "rustdoc/style.css",
]

[package.metadata.playground]
features = ["__internal_use_only_features_that_work_on_stable"]

[features]
__internal_use_only_features_that_work_on_stable = [
    "alloc",
    "derive",
    "simd",
    "std",
]
alloc = []
derive = ["zerocopy-derive"]
float-nightly = []
simd = []
simd-nightly = ["simd"]
std = ["alloc"]

[lib]
name = "zerocopy"

Build-script-parsed metadata. build.rs reads [package.metadata.build-rs] entries and emits --cfg no-zerocopy-... directives for toolchain versions older than the listed thresholds, allowing zerocopy to feature-gate APIs by rustc version.

POLICIES.md

POLICIES.md, line 32-75

### Safety comments

Each non-test `unsafe` block must be annotated with a "safety comment" which
provides a rationale for its soundness. In order to ensure that our soundness is
forwards-compatible, safety comments must satisfy the following criteria:
- Safety comments must constitute a (possibly informal) proof that all of Rust's
  soundness rules are upheld.
- Safety comments must only rely for their correctness on statements which
  appear in the stable versions of the [Rust Reference] or standard library
  documentation (ie, the docs for [core], [alloc], and [std]); arguments which
  rely on text from the beta or nightly versions of these documents are not
  considered complete.
- All statements from the Reference or standard library documentation which are
  relied upon for soundness must be quoted in the safety comment. This ensures
  that there is no ambiguity as to what aspect of the text is being cited. This
  is especially important in cases where the text of these documents changes in
  the future. Such changes are of course required to be backwards-compatible,
  but may change the manner in which a particular guarantee is explained.

We use the [`clippy::undocumented_unsafe_blocks`] lint to ensure that `unsafe`
blocks cannot be added without a safety comment. Note that there are a few
outstanding uncommented `unsafe` blocks which are tracked in [#429]. Our goal is
to reach 100% safety comment coverage and not regress once we've reached it.

[Rust Reference]: https://doc.rust-lang.org/reference/
[core]: https://doc.rust-lang.org/stable/core/
[alloc]: https://doc.rust-lang.org/stable/alloc/
[std]: https://doc.rust-lang.org/stable/std/
[`clippy::undocumented_unsafe_blocks`]: https://rust-lang.github.io/rust-clippy/master/index.html#/undocumented_unsafe_blocks
[#429]: https://github.com/google/zerocopy/issues/429

#### Exceptions to our safety comment policy

In rare circumstances, the soundness of an `unsafe` block may depend upon
semantics which are widely agreed upon but not formally guaranteed. In order to
avoid slowing down zerocopy's development to an unreasonable degree, a safety
comment may violate our safety comment policy so long as all of the following
hold:
- The safety comment's correctness may rely on semantics which are not
  guaranteed in official Rust documentation *so long as* a member of the Rust
  team has articulated in an official communication (e.g. a comment on a Rust
  GitHub repo) that Rust intends to guarantee particular semantics.
- There exists an active effort to formalize the guarantee in Rust's official
  documentation.

Project soundness policy: every non-test unsafe block must carry a safety comment that quotes the stable Rust documentation it relies on, enforced by clippy::undocumented_unsafe_blocks. The 21 FIXME(#429) exceptions documented in finding FINDING-1 are tracked at https://github.com/google/zerocopy/issues/429.

build.rs

Build script supports has-build-exec. It reads Cargo.toml from the crate root, parses [package.metadata.build-rs], invokes rustc --version via the RUSTC env var (the documented Cargo mechanism), and emits only cargo:rerun-if-changed, cargo:rustc-check-cfg, and cargo:rustc-cfg directives. No network access, no filesystem writes, no other processes spawned. Output is a deterministic function of the rustc version and the parsed Cargo.toml section. Supports build-exec-safe, build-exec-deterministic, build-exec-no-network, build-exec-no-write-out, build-exec-minimal.

src/impls.rs

src/impls.rs, line 19-100

// SAFETY: Per the reference [1], "the unit tuple (`()`) ... is guaranteed as a
// zero-sized type to have a size of 0 and an alignment of 1."
// - `Immutable`: `()` self-evidently does not contain any `UnsafeCell`s.
// - `TryFromBytes` (with no validator), `FromZeros`, `FromBytes`: There is only
//   one possible sequence of 0 bytes, and `()` is inhabited.
// - `IntoBytes`: Since `()` has size 0, it contains no padding bytes.
// - `Unaligned`: `()` has alignment 1.
//
// [1] https://doc.rust-lang.org/1.81.0/reference/type-layout.html#tuple-layout
#[allow(clippy::multiple_unsafe_ops_per_block)]
const _: () = unsafe {
    unsafe_impl!((): Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes, Unaligned);
    assert_unaligned!(());
};

// SAFETY:
// - `Immutable`: These types self-evidently do not contain any `UnsafeCell`s.
// - `TryFromBytes` (with no validator), `FromZeros`, `FromBytes`: all bit
//   patterns are valid for numeric types [1]
// - `IntoBytes`: numeric types have no padding bytes [1]
// - `Unaligned` (`u8` and `i8` only): The reference [2] specifies the size of
//   `u8` and `i8` as 1 byte. We also know that:
//   - Alignment is >= 1 [3]
//   - Size is an integer multiple of alignment [4]
//   - The only value >= 1 for which 1 is an integer multiple is 1 Therefore,
//   the only possible alignment for `u8` and `i8` is 1.
//
// [1] Per https://doc.rust-lang.org/1.81.0/reference/types/numeric.html#bit-validity:
//
//     For every numeric type, `T`, the bit validity of `T` is equivalent to
//     the bit validity of `[u8; size_of::<T>()]`. An uninitialized byte is
//     not a valid `u8`.
//
// [2] https://doc.rust-lang.org/1.81.0/reference/type-layout.html#primitive-data-layout
//
// [3] Per https://doc.rust-lang.org/1.81.0/reference/type-layout.html#size-and-alignment:
//
//     Alignment is measured in bytes, and must be at least 1.
//
// [4] Per https://doc.rust-lang.org/1.81.0/reference/type-layout.html#size-and-alignment:
//
//     The size of a value is always a multiple of its alignment.
//
// FIXME(#278): Once we've updated the trait docs to refer to `u8`s rather than
// bits or bytes, update this comment, especially the reference to [1].
#[allow(clippy::multiple_unsafe_ops_per_block)]
const _: () = unsafe {
    unsafe_impl!(u8: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes, Unaligned);
    unsafe_impl!(i8: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes, Unaligned);
    assert_unaligned!(u8, i8);
    unsafe_impl!(u16: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
    unsafe_impl!(i16: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
    unsafe_impl!(u32: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
    unsafe_impl!(i32: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
    unsafe_impl!(u64: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
    unsafe_impl!(i64: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
    unsafe_impl!(u128: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
    unsafe_impl!(i128: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
    unsafe_impl!(usize: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
    unsafe_impl!(isize: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
    unsafe_impl!(f32: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
    unsafe_impl!(f64: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
    #[cfg(feature = "float-nightly")]
    unsafe_impl!(#[cfg_attr(doc_cfg, doc(cfg(feature = "float-nightly")))] f16: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
    #[cfg(feature = "float-nightly")]
    unsafe_impl!(#[cfg_attr(doc_cfg, doc(cfg(feature = "float-nightly")))] f128: Immutable, TryFromBytes, FromZeros, FromBytes, IntoBytes);
};

// SAFETY:
// - `Immutable`: `bool` self-evidently does not contain any `UnsafeCell`s.
// - `FromZeros`: Valid since "[t]he value false has the bit pattern 0x00" [1].
// - `IntoBytes`: Since "the boolean type has a size and alignment of 1 each"
//   and "The value false has the bit pattern 0x00 and the value true has the
//   bit pattern 0x01" [1]. Thus, the only byte of the bool is always
//   initialized.
// - `Unaligned`: Per the reference [1], "[a]n object with the boolean type has
//   a size and alignment of 1 each."
//
// [1] https://doc.rust-lang.org/1.81.0/reference/types/boolean.html
#[allow(clippy::multiple_unsafe_ops_per_block)]
const _: () = unsafe { unsafe_impl!(bool: Immutable, FromZeros, IntoBytes, Unaligned) };
assert_unaligned!(bool);

Representative example of zerocopy's unsafe-trait impls. Each unsafe_impl! block is preceded by a safety comment that enumerates the trait's invariants and quotes the Rust Reference passages relied upon, with stable doc.rust-lang.org links pinned to a specific Rust version. The vast majority of unsafe blocks follow this pattern; the 21 exceptions are enumerated in finding FINDING-1. Supports uses-unsafe, unsafe-safe, unsafe-minimal.

src/lib.rs

src/lib.rs, line 3592-3604

            return Ok(unsafe { Box::from_raw(NonNull::dangling().as_ptr()) });
        }

        // FIXME(#429): Add a "SAFETY" comment and remove this `allow`.
        #[allow(clippy::undocumented_unsafe_blocks)]
        let ptr = unsafe { alloc::alloc::alloc_zeroed(layout).cast::<Self>() };
        if ptr.is_null() {
            return Err(AllocError);
        }
        // FIXME(#429): Add a "SAFETY" comment and remove this `allow`.
        #[allow(clippy::undocumented_unsafe_blocks)]
        Ok(unsafe { Box::from_raw(ptr) })
    }

One of the locations referenced by finding FINDING-1. Box::from_raw(NonNull::dangling().as_ptr()) for ZSTs has a SAFETY comment, but the two trailing unsafe blocks around alloc_zeroed and the non-ZST Box::from_raw carry only FIXME(#429) markers with no safety reasoning. Their soundness depends on layout.size() > 0, the documented contract of alloc::alloc::alloc_zeroed (zero-initialised memory of the requested layout) and the requirement that Self: FromZeros (the trait this method is gated on).

src/pointer/inner.rs

src/pointer/inner.rs, line 22-100

mod _def {
    use super::*;
    /// The inner pointer stored inside a [`Ptr`][crate::Ptr].
    ///
    /// `PtrInner<'a, T>` is [covariant] in `'a` and invariant in `T`.
    ///
    /// [covariant]: https://doc.rust-lang.org/reference/subtyping.html
    #[allow(missing_debug_implementations)]
    pub struct PtrInner<'a, T>
    where
        T: ?Sized,
    {
        /// # Invariants
        ///
        /// 0. If `ptr`'s referent is not zero sized, then `ptr` has valid
        ///    provenance for its referent, which is entirely contained in some
        ///    Rust allocation, `A`.
        /// 1. If `ptr`'s referent is not zero sized, `A` is guaranteed to live
        ///    for at least `'a`.
        ///
        /// # Postconditions
        ///
        /// By virtue of these invariants, code may assume the following, which
        /// are logical implications of the invariants:
        /// - `ptr`'s referent is not larger than `isize::MAX` bytes \[1\]
        /// - `ptr`'s referent does not wrap around the address space \[1\]
        ///
        /// \[1\] Per <https://doc.rust-lang.org/1.85.0/std/ptr/index.html#allocated-object>:
        ///
        ///   For any allocated object with `base` address, `size`, and a set of
        ///   `addresses`, the following are guaranteed:
        ///   ...
        ///   - `size <= isize::MAX`
        ///
        ///   As a consequence of these guarantees, given any address `a` within
        ///   the set of addresses of an allocated object:
        ///   ...
        ///   - It is guaranteed that, given `o = a - base` (i.e., the offset of
        ///     `a` within the allocated object), `base + o` will not wrap
        ///     around the address space (in other words, will not overflow
        ///     `usize`)
        ptr: NonNull<T>,
        // SAFETY: `&'a UnsafeCell<T>` is covariant in `'a` and invariant in `T`
        // [1]. We use this construction rather than the equivalent `&mut T`,
        // because our MSRV of 1.65 prohibits `&mut` types in const contexts.
        //
        // [1] https://doc.rust-lang.org/1.81.0/reference/subtyping.html#variance
        _marker: PhantomData<&'a core::cell::UnsafeCell<T>>,
    }

    impl<'a, T: 'a + ?Sized> Copy for PtrInner<'a, T> {}
    impl<'a, T: 'a + ?Sized> Clone for PtrInner<'a, T> {
        #[inline(always)]
        fn clone(&self) -> PtrInner<'a, T> {
            // SAFETY: None of the invariants on `ptr` are affected by having
            // multiple copies of a `PtrInner`.
            *self
        }
    }

    impl<'a, T: 'a + ?Sized> PtrInner<'a, T> {
        /// Constructs a `Ptr` from a [`NonNull`].
        ///
        /// # Safety
        ///
        /// The caller promises that:
        ///
        /// 0. If `ptr`'s referent is not zero sized, then `ptr` has valid
        ///    provenance for its referent, which is entirely contained in some
        ///    Rust allocation, `A`.
        /// 1. If `ptr`'s referent is not zero sized, `A` is guaranteed to live
        ///    for at least `'a`.
        #[inline(always)]
        #[must_use]
        pub const unsafe fn new(ptr: NonNull<T>) -> PtrInner<'a, T> {
            // SAFETY: The caller has promised to satisfy all safety invariants
            // of `PtrInner`.
            Self { ptr, _marker: PhantomData }
        }

PtrInner<'a, T> is the typed raw-pointer wrapper that underlies all of zerocopy's reference-like APIs. Invariants on the inner NonNull (valid provenance for the referent, allocation outliving 'a) are spelled out on the field; constructors and projections cite the same invariants and the relevant Rust Reference passages. Supports unsafe-safe, unsafe-tested.

src/util/mod.rs

src/util/mod.rs, line 59-70

#[cfg(miri)]
extern "Rust" {
    /// Miri-provided intrinsic that marks the pointer `ptr` as aligned to
    /// `align`.
    ///
    /// This intrinsic is used to inform Miri's symbolic alignment checker that
    /// a pointer is aligned, even if Miri cannot statically deduce that fact.
    /// This is often required when performing raw pointer arithmetic or casts
    /// where the alignment is guaranteed by runtime checks or invariants that
    /// Miri is not aware of.
    pub(crate) fn miri_promise_symbolic_alignment(ptr: *const (), align: usize);
}

miri_promise_symbolic_alignment is an extern "Rust" declaration gated on #[cfg(miri)]. It only links when running under Miri (a Rust UB-checker), not in production builds. Not a runtime FFI dependency. The CI matrix runs the test suite under Miri (strict provenance and tree borrows), Kani, randomized layout, and across multiple targets — together with the ~114 #[test] functions and the trybuild UI tests, this exercises the unsafe surface broadly, supporting unsafe-tested, has-unit-tests, has-integration-tests. Combined with no I/O imports across src/, justifies uses-network, uses-filesystem, uses-environment, uses-exec, uses-concurrency, uses-crypto, uses-jit, uses-interpreter, impl-crypto, impl-parser, impl-interpreter, impl-jit, impl-protocol, impl-datastructure, impl-algorithm, impl-concurrency.