Repository navigation
Remove extern crate alloc from logfwd-core (allocation-free kernel) #358
Description
Summary
After the sequential scanner migration, remove all heap allocation from logfwd-core. The kernel becomes mathematically impossible to OOM — all buffers are stack-local or caller-provided.
What allocates today
- `StructuralIndex`: stores `Vec` for real_quotes and in_string
- `StructuralIndex::new()`: returns `Vec<(usize, usize)>` line ranges
- `CriAggregator`: `pending: Vec` for partial line assembly
- `compute_real_quotes`: no allocation (pure u64 ops)
How to remove allocations
- StructuralIndex → streaming: scanner processes per-block, never stores bitmask vectors. Caller provides iteration context.
- Line ranges: caller (logfwd-arrow) collects, or lines processed inline during SIMD pass
- CriAggregator: caller provides buffer (BytesMut from logfwd-input)
Constraint
`#![no_std]` without `extern crate alloc` means: no Vec, String, Box, Arc, or any heap type. Only stack, references, and caller-provided slices.
Dependencies
- Migrate scanner from ChunkIndex to StreamingClassifier #332 follow-up: sequential scanner (fully streaming, no stored bitmasks)
- Tighten logfwd-core to no_std + forbid(unsafe_code) #267: tighten core to no_std
Why
Allocation-safe verification: if the kernel can't allocate, it can't OOM. Combined with Kani proofs for no-panic, the kernel is provably crash-free for all inputs.
Activity
docs: update all references for structural.rs migration
docs: update all references for structural.rs migration
strawgate commentedon Apr 4, 2026
Status update (2026-04-04 audit)
extern crate alloc is heavily used — 109 occurrences of Vec/String/Box/Arc across 9 files in logfwd-core. Major allocating code: StructuralIndex bitmask Vecs, json_scanner scratch buffers, CriReassembler pending buffer, OTLP encoder buffer, ScanConfig field specs.
This is a multi-PR architecture change requiring all allocations to move to caller-provided buffers. The streaming scanner (json_scanner.rs) is a step toward this but still allocates. Scope: large, not suitable for a single work-unit.
strawgate commentedon Apr 24, 2026
Closing as won't-fix:
extern crate allocis required inno_stdcrates that need heap-allocated types (Vec, String, BTreeMap). This is working as intended — it's the only way to access the alloc crate without std. The issue description was based on a misunderstanding of Rust'sno_stdmodel.