Microsoft quietly published lib0xc on GitHub this week — described in its own README as “a set of C standard library-adjacent APIs for safer systems programming.” It’s MIT-licensed, sits in the official Microsoft GitHub org, and reached the front page of Hacker News today with surprisingly little drama. For a company that’s been pushing Rust adoption inside Windows for the better part of three years, shipping a brand-new C library in 2026 is worth a second look.
What lib0xc actually is
It’s a small collection of header-mostly modules that sit alongside libc. The README breaks it into two halves:
0xc/std/— replacements for things you’d reach for in libc: allocation helpers, formatted I/O, safe integer conversions, string utilities, deferred-call helpers (think Go’sdefer, in C).0xc/sys/— building blocks for systems programs: a logger, a hash table, buffer types, error handling, a unit test harness.
The piece that jumps out is cursor.h — an “allocation-free, in-memory input/output stream” with bounds tracking baked in. Anyone who has audited C code that parses untrusted bytes (network packets, file headers, RPC payloads) knows that 80% of the bugs are in cursor advancement: an off-by-one on a length check, a forgotten bounds test, a signed/unsigned mix-up that lets a one-byte read sail past a buffer’s end. cursor.h takes the discipline of “always carry the buffer length next to the pointer” and bakes it into a type.
The other deliberate choice: lib0xc fully embraces clang’s -fbounds-safety extensions via macro annotations. That’s the same compiler feature Apple has been using to harden the Darwin kernel. It’s not a Microsoft invention — but lib0xc is one of the first widely-visible libraries to design its public API around it.
Why is Microsoft writing C in 2026?
This is the question that makes lib0xc interesting. Microsoft has been publicly bullish on Rust for kernel-adjacent work since 2022 — chunks of the Windows kernel are now Rust, the GraphQL parser in Azure Cosmos DB is Rust, and the Azure boot stack is moving that direction too. So why ship a new C library?
The honest answer is that “rewrite it in Rust” is a multi-decade arc, and in the meantime an enormous amount of code stays in C. Drivers. Firmware. Hot-paths in databases. Code that has to interop with C ABIs, link against C-only libraries, or compile without a Rust toolchain present. The choice is not “Rust or C” — it’s “C with 1995-era tooling, or C with bounds-aware types and stricter compile flags.” lib0xc is a bet on the second.
It’s also a bet that’s structurally similar to what the Linux kernel community has been doing with Rust-for-drivers and what the C2y standards committee has been doing with bounds-checking interfaces (Annex K, memcpy_s, etc.) — except lib0xc is not waiting on the standards committee, and it’s not pretending C is going away.
Who wins, who loses
Wins: teams maintaining mid-sized C codebases that can’t realistically port to Rust. Specifically, anyone whose code parses bytes from an external source — protocol handlers, log parsers, image decoders, anything that takes a (buffer, length) pair and walks it. The cursor pattern is the kind of thing you can adopt in one file at a time, without a flag day, and the static-bounds-checking macros work alongside whatever style guide the team already has.
Loses: nobody, really, but the slower-moving safety alternatives — Annex K, the various competing “safe C” libraries — get less oxygen. lib0xc has Microsoft’s name on it, an MIT license, and is small enough to read in an evening. That’s a hard combination to beat for greenfield projects choosing a baseline.
What to do this week
If you maintain a C codebase that handles untrusted input — even partially — give yourself 30 minutes to read cursor.h and the integer-conversion module. You don’t have to adopt the whole library. Steal the patterns. The cursor type is maybe 200 lines and would replace a lot of hand-rolled “advance the pointer, check the length” code in most codebases I’ve seen. The trapping integer cast (int_cast_to_u32_or_die-style) is even shorter and would have caught real bugs.
The deeper trend lib0xc points at is worth naming directly: the industry has stopped treating “use Rust” as a complete answer to memory safety. Rust is part of the answer. So is hardening the C that isn’t going anywhere. The next decade of systems programming is going to look less like a single-language migration and more like a multi-pronged push — Rust for new code, lib0xc-style libraries for code that stays C, -fbounds-safety annotations layered on both, and standards work creeping forward in parallel.
For a Microsoft project shipped without a press release, that’s a surprisingly clear thesis.
Source: github.com/microsoft/lib0xc (README, MIT-licensed). Cover photo by technobulka on Pexels.