RFC: a differentially-certified memory-safe Rust port of libogg's bitwise.c + framing.c — would Xiph want this?

[anthonyadame]

Hi,

I'd like to offer Xiph a memory-safe Rust port of libogg's two core translation units —
bitwise.c (oggpack/oggpackB) and framing.c (page/packet framing, CRC, sync/resync) —
and ask how, or whether, you'd want it upstream.

What exists today

• A zero-dependency, #![forbid(unsafe_code)] Rust crate covering both units, ported from
  the pinned 1.3.6 tarball and licensed BSD-3-Clause identical to upstream.
• A byte-differential certification harness: both the C build and the Rust port are driven
  by the same op-script driver over a 582-case envelope (every bit width 0–32 in both
  packing modes, buffer-growth boundaries, lacing edges at 255/65025, continued pages,
  granulepos extremes, bos/eos, both decode paths — sync_pageseek and sync_pageout +
  packetpeek — scatter-gather iovecin, pageout_fill/flush_fill, resets, CRC
  corruption at every interesting header offset, truncation, mid-stream resync, single-byte
  sync feeding, and seeded random op soups). The complete stdout of both implementations is
  byte-identical across all 582 cases. The golden outputs regenerate from your C build, so
  the claim is independently checkable.
• An honest coverage statement: the only functions not differentially certified are the
  allocation/teardown calls with no observable output (*_destroy, ogg_packet_clear);
  everything with differentiable behavior is covered.

Disclosure on how it was made

The port was produced by an automated translation pipeline (LLM-assisted) whose acceptance
gate is the differential certification above — not human review of the generated code. I'm
stating that plainly because you should weigh it: the trust anchor here is the byte-exact
behavioral match against your own reference implementation over an adversarial envelope,
plus the compiler-enforced absence of unsafe. Where the envelope doesn't reach, I make no
correctness claim yet.

What I'm asking

Which of these, if any, would be welcome?

1. A Xiph-hosted sibling project (the rav1e model): e.g. xiph/ogg-rs, with the
   differential suite in CI pinned against libogg releases.
2. In-tree contrib: the crate under contrib/rust/ (or similar) in xiph/ogg, with a CI
   job that builds the C reference and replays the envelope on every commit.
3. Neither, but guidance on what evidence bar or scope (e.g. full-API envelope coverage,
   a C-ABI -sys layer, fuzzing parity with oss-fuzz) would make this worth revisiting.

I'm happy to extend the envelope to the uncovered API surface, add a C-ABI compatibility
layer, wire up CI, and maintain it.

Crate, harness, envelopes, and goldens: https://github.com/Kaizen-3C/libogg-rs
(CI rebuilds the C reference from your release tarball and re-proves the differential on
every commit.)

Thanks for the decades of libogg,
Anthony Adame