Blog

Panics in Rust by default unwind to run Drop implementations for all values on the stack. Rust's stack unwinding is implemented using the same mechanism as C++ exceptions on most platforms. Recently the Cranelift code generator got support for "landingpad" style exceptions as detailed in the corresponding Cranelift RFC allowing me to add support for unwinding on panics to rustc_codegen_cranelift (cg_clif) for Unix systems.

In this article, I'll show you how exception handling works in cg_clif by walking you through several layers of the compilation process all the way to the runtime behavior.

Fuzz testing is incredibly useful: it has caught many a bug during the development of NTP packet parsing and gzip/bzip2 (de)compression.

But I've always been unsatisfied with the fuzzer being a black box. When it runs for hours and reports no issues, what do we actually learn from that? In ntpd-rs we've previously had a bug fly under the radar because the fuzzer just did not reach a large chunk of code. So, does my fuzzer actually exercise the code paths that I think it should?

While using a full-blown filesystem for storing your data in non-volatile memory is common practice, those filesystems are often too big, not to mention annoying to use, for the things I want to do. My solution?

I've been hard at work creating the sequential-storage crate. In this blog post I'd like to go over what it is, why I created it and what it does.

While working on the Roc compiler, we regularly dive deep on computer science topics. A recurring theme is speed, both the runtime performance of the code that we generate, as well as the performance of our compiler itself.

One extremely useful technique that we have been playing with is data-oriented design: the idea that the actual data you have should guide how code is structured.