Ismail Badawi

Automatic Directory Creation in Make

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 a 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.

Unintended StopIteration in a Generator

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'))

A Bug Caused by Using 0 Instead of NULL

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:

When Optimizations Hide Bugs

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 optimized out.

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.

The Compositional Nature of Vim

I use vim. I’ve used vim since I started programming; the very first program I wrote – hello world in C, following along a tutorial – was typed out in vim, inside a cygwin environment on Windows. Naturally, at first it was hard and intimidating. I didn’t know how to do anything, least of all edit text. I learned about insert mode and normal mode. I learned about navigating using hjkl, and deleting the current line with dd, and saving and quitting with :wq, and for a long time that was it.

An Obscure Bug Story

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.

Writing a Code Coverage Tool

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.