[justinchuby]

Root cause

platform_capacity.rs hand-declared a #[repr(C)] struct StatVfs to call statvfs(3). That declaration matches 64-bit glibc only. On macOS fsblkcnt_t/fsfilcnt_t are 4 bytes, not 8, and there is no trailing f_spare member — so a 112-byte struct was laid over a real 64-byte one.

f_blocks and f_bfree were read as one fused u64, the garbage overflowed checked_mul, that returned None, and the disk reported as unmeasurable.

Measured, not assumed

Compiled and ran a C program against <sys/statvfs.h> on arm64 macOS:

sizeof(struct statvfs) = 64        alignof = 8
sizeof(fsblkcnt_t) = 4             sizeof(fsfilcnt_t) = 4      sizeof(unsigned long) = 8
offsetof: f_bsize 0, f_frsize 8, f_blocks 16, f_bfree 20, f_bavail 24,
          f_files 28, f_ffree 32, f_favail 36, f_fsid 40, f_flag 48, f_namemax 56
live:     f_frsize=4096 f_bsize=1048576 f_blocks=242837545 f_bavail=19132442

The damage was wider than the fused block counts: f_fsid/f_flag/f_namemax were also at wrong offsets (the old declaration implied f_fsid at 64; the real offset is 40), and f_spare does not exist on macOS at all. Only f_bsize/f_frsize were correct. A fix driven purely by the reported symptom would have left two of these in place.

Fix: use libc's definition, don't hand-roll one

The struct is now libc::statvfs. libc was already in this crate's dependency graph via memmap2 and tokio — both direct dependencies — so declaring it explicitly adds no new package. The Cargo.lock delta is literally one line:

 crates/onnx-genai-engine dependencies:
+ "libc",

libc defines the layout per target, so there is no longer a layout in this crate to get wrong — on macOS, on Linux, or on the other unixes an earlier revision of this PR left with the broken widths.

This is a net deletion: two type aliases, a cfg'd-out f_spare, two compile-time size guards and a field-offset table all go away.

Verification

Before (reverse-verified against the unmodified tree)

test platform_capacity::tests::disk_capacity_is_measured_for_the_working_directory ... FAILED
panicked at crates/onnx-genai-engine/src/platform_capacity.rs:293:55: disk must be measurable here

test engine::tests::an_explicit_byte_limit_is_honored_without_a_device_query ... FAILED
panicked at crates/onnx-genai-engine/src/engine/mod.rs:1388:87:
called `Result::unwrap()` on an `Err` value: UnmeasuredCapacity { tier: "disk spill" }

After

Both pass. Full crate suite: 430 passed; 0 failed; 1 ignored.

Executed

• The C layout probe, on this macOS host.
• Both named tests failing before / passing after; full engine lib suite.
• The exact CI command that went red — cargo clippy --locked --all-targets -p onnx-genai-engine --features native-backend -- -D warnings — now clean for this crate.
• Linux was compiled, not just reasoned about. platform_capacity.rs has no crate-internal dependencies, so it was built standalone for x86_64-unknown-linux-gnu against libc's real Linux struct statvfs, under -D warnings. Clean. A full-workspace Linux cross-build is not possible here (onnx-genai-ort-sys needs a Linux C sysroot for bindgen), so this is the module, not the whole crate.
• cargo fmt --check clean.

Not executed

Linux test execution, and Windows anything. Those need CI.

On the CI failures for this PR

main is currently red on its own, so "CI is red" is not by itself attributable here. Run 32388200098 is main at 3b3e5f79 — this PR's exact merge-base — and it already fails the same job and same step for:

• CUDA compile (Linux x86_64) → Verify CUDA test inventory and skip honesty (tracked as matmul_nbits_marlin_numerics silently skips instead of failing loud, so the CUDA honesty guard is red on main #1589)
• CUDA compile (Windows x86_64) → Clippy CUDA execution provider
• Rust (Windows ARM64) → Test cross-platform offline crates
• Rust coverage (Windows x86_64) and Rust coverage (macOS arm64) → Test cross-platform offline crates with coverage

Those coverage/offline lanes do not include onnx-genai-engine at all — python .github/scripts/workspace_test_packages.py cargo-args offline-cross-platform does not list it — so this PR cannot be their cause. Pre-existing, not addressed here.

Rust quality was genuinely mine. It passed on main at 3b3e5f79 and failed here. Cause: an earlier revision used u64::from(buf.f_blocks), which on Linux is a u64→u64 identity and trips clippy::useless_conversion under -D warnings — precisely the Linux-only blind spot flagged as unverified. Reproduced locally by forcing the Linux widths, and fixed: the libc version uses plain as u64 casts under one function-level allow, matching what the surrounding code already does for f_frsize/f_bsize.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.78%. Comparing base (3b3e5f7) to head (f1b307d).
⚠️ Report is 12 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff            @@
##             main    #1586    +/-   ##
========================================
  Coverage   80.77%   80.78%            
========================================
  Files         381      381            
  Lines      173645   173786   +141     
  Branches   173645   173786   +141     
========================================
+ Hits       140264   140386   +122     
- Misses      28491    28505    +14     
- Partials     4890     4895     +5     

Flag	Coverage Δ
cli-ort-linux	82.60% <ø> (ø)
cli-ort-windows	82.10% <ø> (-0.10%)	⬇️
mlas	85.05% <ø> (-0.04%)	⬇️
offline	80.64% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 5 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.