TLB Hit 💥

In this episode, Chris and JF dive into the world of code coverage and fuzzing. They explore why coverage matters, the types of coverage metrics, and how fuzzing helps uncover unexpected software behavior. From the practical trade-offs of MC/DC testing to the randomness of AFL’s mutators, the hosts discuss techniques, tools, and the balance between robustness and resiliency. Tune in for insights, laughs, and maybe even a recommendation to "go fuzz yourself!"

Monitor. Compile. Bail. Repeat!

* What is it we know statically? * What's effectively discoverable only at runtime? * How do we tell "the machine" (compiler and/or hardware): * Things we *know* to be true... * Things we *expect* to be true... * Things we *expect* to be true but *want to do something about* when it's not... * Things we have no idea about! * How do we collect that information that we have no idea about? * What happens if we're wrong? What if the workload is inherently irregular? * In the limit, random noise could drive our control decisions! * We talked a bit about precise vs imprecise exceptions before and automatic reordering, and we've mentioned vector machines and auto-vectorization. * All falls into the broader theme here, but we're always questioning what we can actually cover in an hour... * We'll try to give it a go for a subset of these things! * Time is often the limiting factor. * The episode title is the thing that we often macro define as `#define UNLIKELY` * In C/C++ code you might say "this control condition is unlikely", and say `if (UNLIKELY(condition))` * In C++20 there was added these `[[likely]]` and `[[unlikely]]` annotations that do the same thing, but with more square brackets, so clearly better!

What happens when you type https://tlbh.it in your browser's address bar, and press enter?

The adventure of storing to !