Identifies the small set of raw-memory operations, required safety assumptions, tests, and future containment needed to preserve Rust’s safety value.
Implementation evidence: this topic is grounded in the reviewed GGUF.MiRust.com source snapshot. It documents observed code and artifacts without claiming broad deployment, model quality, or production readiness.
Observed unsafe code
The runtime permits unsafe code in the memory and raw ABI boundary. It reconstructs allocations from raw parts and creates slices from caller-provided pointers and lengths.
Safety assumptions
- The pointer came from the active WASM memory.
- The range is allocated and live for the complete call.
- The provided length is the exact allocation capacity for deallocation.
- No host view is used after deallocation or memory growth invalidates it.
Containment
Math, parsing, tokenization, model logic, server, and harness paths remain safe Rust. Future ABI work should encapsulate allocation handles, add generation counters or opaque IDs, and fuzz the raw boundary under malformed pointer/length combinations available to the host.
Scope
This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.
Engineering considerations
- Identify the source, version, target environment, and owner.
- Separate observed values from estimates and externally reported values.
- Record trade-offs, unsupported cases, and fallback behavior.
- Link performance statements to a compatible benchmark methodology.
Verification questions
- What exact artifact, revision, backend, and environment were reviewed?
- Which assumptions could change the result?
- Which data should be retained so another engineer can reproduce the conclusion?