When I was in grad school and struggling with my Master’s thesis, I started a small side project in order to distract myself and work on something that felt more rewarding. This project was basically a clone of vim – a terminal-based text editor I called badavi. That was around seven years ago. I haven’t worked on it continuously since then, but I would occasionally go back and hack on it in short little bursts. In particular I’ve been doing this the last couple of months, and I thought it might be interesting to write about some of the things I’ve been up to.
I like out-of-tree builds. Out-of-tree builds are nice for lots of reasons. You
can have multiple builds of the same project coexisting side-by-side – for
example a debug build for development, a release build, and an instrumented
build for code coverage runs. All the generated build artifacts are together
underneath one directory which you can easily delete without having to maintain
make clean target, or place under
.gitignore without having to maintain a
growing set of patterns for the different kinds of artifacts. I was going to
write a post about this, but came across
this one by Jussi Pakkanen which covers a lot of the
ground I would have, so I’ll just link to it here.
Instead, this post is about an issue that arises when implementing out-of-tree builds in make, and the best approach I’ve found for dealing with it.
Sometimes, if I have a generator that I happen to know is non-empty, and I want to get at the first element, I’ll write code like this:
output = next(f for f in os.listdir(dir) if f.endswith('.o'))
This is a small gotcha about file permissions I ran into recently.
This is a quick post about a bug I ran into at work which turned out to be
caused by passing a literal
0 instead of
NULL to a function. Here’s a
small program reproducing it:
The past few months at work I’ve been working with a large legacy codebase,
mostly written in C. In order to debug problems as they come up, I wanted to
use gdb – but it seemed like the program was only ever compiled with
optimizations turned on (
-O2), which can make using gdb a frustrating
experience, as every interesting value you might want to examine has been
After grappling with the build system to pass
-O0 in all the right places (a
surprisingly difficult task), I found that the program did not link with
optimizations turned off. Once I got around that, I ran into a crash in some
basic functionality, easily reproducible at
-O0, but not
-O2. This post
contains two tiny contrived programs reproducing those issues.
It’s common to be asked a question like “what’s the hardest bug you’ve debugged?” at job interviews in tech. This post is about the bug I usually describe. The snag is that it’s quite involved and I don’t actually understand it all the way through – there are one or two aspects to it I often hand-wavingly gloss over. The hope was that by writing it out and fact checking it I’d have a better handle on it; this is what came out.
Disclaimer: I’m not quite sure who the audience is for this. I guess it’s describing a fun little project I put together, but it’s also written kind of like a tutorial, so you can maybe follow along. I don’t think it’s particularly beginner-friendly, though. Some knowledge of Java is assumed, but not much. The code is available on github.
Code coverage is a software metric that measures how much, and which parts, of the source code of a program were exercised in a given execution of that program. There are many different flavors of coverage data, for example tracking which lines or statements were executed, which functions were called, which branches or control flow paths were taken. In this post, we’ll walk through writing a simplistic coverage collection tool for Java.