I'm happy to announce that ocaml-wire 1.0.0 is now on opam, installable with opam install wire.

This release brings a round of robustness fixes and API cleanups to the previous version (hence the 1.0.0 tag). It also adds a lot of differential testing between the OCaml parsers/serialisers and the generated verified C parsers. Both are run on randomly generated schemas and random input bytes, and the test checks that they agree on what they accept or reject, and on the values they decode. Wherever they disagreed there was a bug, and those all seem to be fixed now.

But how can these be interpreted as signed integers or floats? Is this left to the layers above?

EverParse 3D has no signed or floating-point types, only unsigned integers, so to the C validator an int8 is a UINT8 and a float64 is a UINT64. The OCaml decoder does the reinterpretation, two's complement for the signed types and IEEE 754 for the floats, and for a plain field both sides accept every bit pattern. A constraint on the field (that the user would have added via the DSL) has to survive that projection. A signed ordering constraint has to be rewritten through the two's-complement identity before it reaches the C validator, because a naive unsigned comparison disagrees on bytes with the sign bit set (byte 200 is the signed value -56, accepted by OCaml and rejected by the naive C bound). Float finiteness (is_finite, is_nan) compiles to a test on the exponent bits, and a float ordering constraint, which has no faithful unsigned form, is rejected up front. The differential fuzzing is what surfaced those sign-bit disagreements and all of this has been hardened between 0.9 and 1.0.

Zero-copy reads got safer too. Codec.validate now enforces every check Codec.decode does (enum membership, bounds, padding, where clauses), so validating untrusted input before a batch of zero-copy Codec.get calls no longer trusts bytes the decoder would have rejected (again, caught thanks to differential testing).

The generated .3d files also turned out to be quite readable as protocol descriptions, and a whole codec family now projects to a single .3d that doubles as a spec and compiles to a standalone verified C parser with no FFI. The TCP/IP stack is a good one to compare: the OCaml definitions and the generated 3d file.