What we replace and why

Most serious vulnerabilities in C libraries are memory-safety bugs. A Rust implementation written from the specification, exporting the original C ABI, removes that bug class while leaving every caller untouched. We do not translate the C; we implement the published standard and verify against the upstream test suites.

Projects

expat-rs

Released, v0.2.0 on crates.io · MIT

XML 1.0 parser written from the W3C specification, replacing libexpat. libexpat is linked by CPython, Apache httpd, D-Bus, fontconfig, and in Android by ART and Skia.

Shipped: streaming parser, namespaces, encoding detection, bounded entity expansion with tests for billion-laughs and quadratic-blowup inputs, fuzz targets, no unsafe code. Matches libexpat 2.8.2 on the W3C conformance suite.

In progress: a libexpat-compatible C library (libexpat.so / .dylib) covering the CPython and xmlwf surface; CPython 3.14 building against it is the next milestone, Android testing to follow. Next release: 0.3.0.

cjson-safe

Released, name reserved at 0.0.1; full release pending · MIT

JSON parser written from RFC 8259 with a drop-in libcjson C ABI, replacing cJSON. All 78 cJSON.h functions implemented; 100% pass on the public-API subset of upstream tests; forbid(unsafe_code) core with a Miri-clean FFI shim; about 4.5 million libFuzzer and AddressSanitizer iterations with no crashes.

Floyd

Released, v0.2.1 on crates.io · MIT or Apache-2.0

Open-source MC/DC (Modified Condition/Decision Coverage) engine for Rust. Floyd recovers decisions from the compiler’s MIR and reports, under masking MC/DC, which conditions in each decision your tests exercise. MC/DC is the structural coverage ISO 26262 asks for at ASIL D and DO-178C at Level A; llvm-cov does not provide it for Rust.

Install with cargo install cargo-floyd, then run cargo floyd test in any Cargo project. Output: text, JSON, JUnit XML, with CI examples for GitHub Actions, GitLab, Jenkins and Buildkite. Floyd reports no result for a decision shape it does not recognise, rather than a wrong one; the supported and unsupported shapes are listed in the README.

Qualification: Floyd targets ISO 26262 TCL3 by validation. The repository carries a corpus of decision patterns with hand-computed MC/DC analyses, re-checked by CI on every commit.

Floyd Enterprise

The open-source engine is complete as a coverage tool. Floyd Enterprise is what a safety team needs to put it into an ISO 26262 evidence package.

Tool qualification kit. The packaged evidence for ISO 26262-8 clause 11: TCL3 classification argument, tool validation suite with the ground-truth corpus and its results against the released binary, safety manual, and the plans an assessor expects to see. Delivered per Floyd release, against named Rust toolchain versions.

Extended decision recovery. Decision shapes the open-source engine declines (tuple-returning multi-decision functions, match guards, nested pattern destructuring, async desugaring, FnMut closures mutating captured state), so reviewers see coverage for the whole codebase rather than a supported subset.

Assessor-facing reports. Reviewer-oriented HTML reports built from the engine’s independence data: for each decision, its conditions and the pair of test observations that shows each one acting independently. Designed to be read by an assessor, not parsed by CI, and going beyond the text, JSON and JUnit output of the open-source engine. Report formats are delivered as part of an engagement.

Support and qualified updates. Named-contact support with response commitments, and a qualified update channel so each Floyd and toolchain release arrives with its kit already revalidated.

Licensing is per programme.

Enquire about Floyd Enterprise

Assess, convert, verify, hand over.

  1. Assess

    Map the C dependency, its consumers and its CVE history. Decide whether a drop-in replacement, a safe wrapper or a staged rewrite is the right call. Sometimes the answer is to leave it.

  2. Convert

    Rust implementation written from the specification, behind the existing C ABI, so consumers relink rather than rewrite. Unsafe code confined to a thin, audited FFI layer.

  3. Verify

    Upstream test suites, specification conformance suites, differential fuzzing against the original, Miri on the FFI boundary, and MC/DC coverage with Floyd where the standard requires it.

  4. Hand over

    Your team owns the code, the tests and the evidence. Documentation written for the engineers who maintain it and the assessors who audit it.

A C library you would rather not keep patching?

Tell us what it is and where it runs. We will tell you whether replacing it is worth it.

Start a conversation