OCaml Weekly News

Hi everyone,

opam 2.5.2 is now available. This release is fixing:

• a security issue (OSEC-2026-10)
• a regression from 2.5.1 preventing cross-compiled packages that use dune from installing properly (ocaml/dune#14393)

We invite everyone to upgrade to 2.5.2 as soon as possible.

If you depend on the older opam package of your preferred distribution, maintainers of distributions such as Debian Stable have been notified and we expect backporting of the relevant fixes to be available there very soon.

You can read our blog post for relevant links and details.

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.

I am happy to announce the release of Caqti 3.0.0. This release bundles some breaking changes including switching to hierarchical modules. The Caqti 3 API is mainly a reorganization of the caqti.template preview library and some remaining modules from the Caqti 2 API.

Release notes:

• The caqti library now holds the Caqti 3 API and caqti.classic contains a Caqti 2 compatibility wrapper. Users of the Caqti 2 API must now add caqti.classic to their link lines. Early adopters of the Caqti 3 API must replace caqti.template with caqti and adjust some module paths. Switching to the new API is recommended, but may be done incrementally for existing applications.
• Fixed initial comma when formatting rows, affecting Caqti_type.pp_value (Caqti 2) and Caqti.Template.Row.pp (Caqti 3).
• Put on hold deprecation of the caqti-dynload package due to issue #140.
• Foreign key constraints are now enabled for SQLite by default.

It's good if opam-released projects add caqti.classic to their link lines before their next release (or switch API) and raise the lower bound on caqti to 2.3.0 (cf the previous announcement) if necessary.

ocgtk 0.1-preview2 is now available on opam

This release significantly increases the amount of generated functionality, covering the vast majority of classes snd methods available in it’s generated libraries (GTK, Gio, Pango, Cairo, GDK, GDKpixbuf, Graphene)