I’m a newcomer to Zig, and one of the interesting use-cases I see for it is to add unit tests to a legacy C codebase.
The cool thing about Zig’s C interop is that you can unit test a C codebase without modifying anything about the C code or the existing build system.
As a proof of concept, I tried adding unit tests to a C utility that I use every day. I had to learn a few different new Zig concepts, but I got it working:
I found the experience a good way to learn more about Zig with a gentle learning curve. I’ve seen other posts about maintaining C applications in Zig, but the first step is always to rewrite the Makefile as a build.zig file. That always felt like a major barrier to entry, so I wanted to show a way of maintaining a C project with Zig that doesn’t require rewriting existing build logic.
Nice write-up! I appreciate you documenting your raw experience of working through the meaning of more complex (but common) pointer types for the first time. In my opinion that’s one of the trickier aspects of Zig to learn, maybe by necessity, but seeing your thought process is a reminder that it is always possible to use logic to work it out if you understand the underlying primitive concepts.
Yeah, I actually find writing it out helpful for learning about Zig as well.
If I’m not writing, I fall into sloppy thinking and just try stuff and often forget the results. Like I’ll do some std.debug.print to test a hypothesis, then I’ll forget 10 mins later what I did or what I learned.
If I’m keeping notes, it forces me to keep track of where I’m going and makes it easy for me to retrace my steps and confirm my understanding. Plus, as a cool side effect, people give me feedback about ways to simplify or improve.
