I reconstructed filenvercmp from disassembly — and it passed 34,145/34,145 after failing 791

For the last weeks I've been rebuilding GNU coreutils filenvercmp by hand from disassembly (no source code). The function is inside /usr/bin/ls and handles version-aware sorting — the reason ls -v orders file1.2, file1.9, file1.10 in the right order.
This post is about how the differential-verification method worked for me, what failed, and why it matters for people who love low-level systems.
I built two sealed corpora (34,145 pairs each, one per seed). The oracle was the native binary itself via mmap (read-only). The reconstruction initially "passed" 32,000 synthetic cases, then failed 791. After debugging the exact mismatch classes (digit-run semantics, extension-chain handling, ~ ordering, end-of-string sentinels), it passed the final matrices: 0/34,145 divergences across 2 independent generations.

I built two sealed corpora

The corpora are mine — those are 34,145 pairs of filenames each (one per generation), sealed with SHA-256 before generating the matrix. The oracle is the native binary itself (/usr/bin/ls mmap'd, read-only) — every line of matrix_native.txt is one integer per case: the exact return value of the native function on that pair of names.
The harness is 200 lines of C. It reads both files and compares the reconstruction against the native answer byte-by-byte. Tolerance zero.

What failed, and why it's interesting

My first reconstruction "passed" 32,400 cases and was wrong. The mismatch rate with a larger corpus was ~3.4% — believable symptoms: . inside names, extension chains, ~~, trailing digits with leading zeros, empty sides, UTF-8 bytes.
None of those were caught by random testing — only by a dense corpus targeting the actual discriminators. The fix took multiple iterations (791 → 97 → 86 → 0).

What got verified and what didn't

Verified (my host, my UID, my model):

  • filenvercmp / verrevcmp / file_prefixlen: 0 divergences across 2 generations (2 × 34,145)
  • wc (the full wc behavior, default flags + -c/-l/-w/-L combinations): 0 divergences across 6 corpora (~37,000 cases), both LC_ALL=C and es_AR.utf8
  • Byte-audit of all 256 byte classes in LC_ALL=C; NBSP (0xa0) discovered as a separator — found via the discriminating corpus, not by assumption Not verified (honest):
  • third-party verification — nobody independent has run the harness yet. That's the actual missing piece.
  • port 1:1 of the LSM from disassembly — the reconstruction is semantic-equivalent, verified by differential testing, not by instruction-level identity.
  • No PASS claim for any engine or project beyond these artifacts. ## Please reproduce, or refute — both are valuable If you can run 4 commands, you can independently verify this. The package has everything you need: git clone https://github.com/LexLuthorPrimero/rxre-cleanroom.git cd rxre-cleanroom sha256sum -c SHA256SUMS gcc -std=c11 -Wall -Wextra -Werror -O2 -o verify2 src/filenvercmp.c harness/verify2.c ./verify2 oracle/cases_seed20261112.txt oracle/matrix_native.txt ./verify2 oracle/cases_seed20261113.txt oracle/matrix_native_20261113.txt Expected: total=34145 mismatches=0 twice. Also maybe interesting: /usr/bin/wc reconstructed the same way, verified on two locales and multiple corpora.
  • Repo: https://github.com/LexLuthorPrimero/rxre-cleanroom
  • Issue #1 for reporting: https://github.com/LexLuthorPrimero/rxre-cleanroom/issues/1 ## Why I'm posting Because I'm not allowed to verify myself — the project's own closure rule requires third-party verification, and asking strangers to help is the only honest way to close it. If you've ever wondered how to trust an AI-generated binary reconstruction, this is an opportunity to witness the closure protocol. One verified result ("it works on my machine too") would be invaluable — both to make the project real, and to set a precedent for open-source AI-assisted verification pipelines.