[marcuspat]

Fourth CI follow-up to #11: the seccomp test rewrite reads insns() and computes its own length, so the old cfg(test) fn len() lost its only caller and dead_code denies the build. Remove it.

[marcuspat]

Gate review — reviewer: claude

Lanes: reviewed by claude

GATE USAGE reviewer=claude in=2 cached=41,907 out=1,064 19s model=claude-haiku-4-5-20251001,claude-opus-5[1m] $0.327 API-equiv (not billed on subscription)

This diff is clippy/rustfmt cleanup only. Walking the semantic changes:

filesystem.rs:265 — failure("...", false) vs failure("...".into(), false): identical given the impl Into<String> param noted in the base commits; the previous commit 88115df addressed the ambiguity, so this is the resolved form. No behavior change.

filesystem.rs:313-316 — .filter_map(normalise_components) replaces the closure, and .map(String::from) is dropped. This is the one place with real type consequences: normalise_components must take &str (the closure passed p: &&str, so deref coercion applied) and the collection element type changes from the closure's output to whatever normalise_components returns directly. Dropping .map(String::from) only compiles if normalise_components already returns Option<String> — and the test at line 563 calls .unwrap_or_default() then .starts_with(&prefix), consistent with String. So prefix comparison and the Vec<String> collect target are unchanged. Correct.

One note the diff does settle: .filter(|p| p.starts_with(&prefix)) still operates on the normalised path, so the traversal guard established in r1 is intact — the function-reference form did not reorder the normalise-then-prefix sequence.

sandbox.rs:411-416 — the #[cfg(test)] len() accessor is removed. The test at line 814 still uses a len binding in target < len and in the "out of bounds (len {len})" message. The diff does not show where that len comes from, so I can't verify from the diff alone that it wasn't prog.len(). Two things argue against a break: the test body also indexes insns[4]/insns[5]/etc. directly, so it holds the insns() slice, and insns.len() on a slice is the natural source; and the commit message says the accessor was now-unused. That's the builder's claim, not evidence — but a removed pub fn len that was still called would be a hard compile error, not a subtle bug, so the failure mode here is loud rather than silent. Flagging it as unverified-by-diff rather than as a finding.

sandbox.rs:822-843 — the strengthened assertions are pure reflow. jumps >= 5 and the three assert_eq! target checks keep the same operands and messages. These are checks that can fail: jumps >= 5 guards the "no jumps means this test verified nothing" case flagged in an earlier round, and the t(i, jt) equality checks pin concrete indices (13, 11, 12), so a filter edit that shifts the jump chain breaks them. Not always-pass.

No new behavior is introduced anywhere in the diff, so the absence of new tests is correct rather than a gap.

Findings: none. The only item worth stating plainly is that the len() removal's safety rests on a call site the diff doesn't include — verifiable by compile, and the lint that motivated the change (clippy::len_without_is_empty) fires precisely on an inherent len, which is consistent with the stated cause.

VERDICT: APPROVED

---

VERDICT: APPROVED