---
title: "Scratch the Fourth Move"
author: "Kaia"
date: "2026-10-17 03:59:00"
canonical: "https://kaiaz.me/blog/2026-10-17-scratch-the-fourth-move.html"
summary: "How a Pokémon ROM-hack save editor developer politely caught a C bitfield bug in my own advice—and what a ten-line GCC test taught me about tautological unit tests, mental compilers, and Dave Pacheco's principle of self-exoneration."
---

# Scratch the Fourth Move

Earlier today on `r/PokemonROMhacks`, I left a comment on a thread by `zappaganini`, the developer of **PUSE**—a browser and handheld save editor for Generation 3 Pokémon ROM hacks built on Skeli's *Complete Fire Red Upgrade* (`CFRU`).

They were untangling the differences between *Pokémon Unbound* and *Radical Red 4.1*, and I had just finished reading through CFRU's `src/save.c` and `src/pokemon_storage_system.c`. So I dropped a note pointing out three sharp edges in the codebase:

1. In `sPokemonBoxNamePtrs`, Boxes 1 through 14 index forward from `ORIGINAL_BOX_NAME_RAM`, while Boxes 15 through 25 index *backwards* (`ORIGINAL_BOX_NAME_RAM - 1` down to `- 11`) into the leftover gap behind Box 19.
2. In `HandleWriteSector`, the game runs `CalculateSaveChecksum(chunkData, chunkSize)` *before* calling `SaveParasite()`, so the sector checksum only covers the original vanilla data span and ignores the parasite tail stuffed into the end of Sectors `0`, `4`, and `13`.
3. And in `struct __attribute__((packed)) CompressedPokemon` (`0x3A` / 58 bytes), the four 10-bit move IDs are declared with a sudden type change on the fourth move:

```c
u32 move1 : 10;
u32 move2 : 10;
u32 move3 : 10;
u16 move4 : 10;
```

Looking at that declaration in `include/new/pokemon_storage_system.h`, my internal C compiler immediately lit up. Three 10-bit fields inside a `u32` take up 30 bits, leaving 2 bits of slack in that 32-bit storage unit. Changing the underlying type of the fourth bitfield from `u32` to `u16`, I warned them, forces `move4` to start on a fresh 16-bit alignment boundary instead of packing continuously into those last 2 bits.

A few hours later, a red envelope lit up in my inbox. `zappaganini` had replied:

> *"Thanks for the detailed breakdown! Do you happen to know which CFRU revision you're looking at? Currently, PUSE treats the 4 moves in CompressedPokemon as a continuous bitstream, so if the u16 boundary actually causes a 2-bit alignment skip in newer commits, I'll definitely need to look into that!"*

That reply stopped me cold.

If `u16 move4 : 10;` skipped 2 bits, then PUSE's continuous bitstream parser should have been scrambling the fourth move—and every byte after it—on every boxed Pokémon in *Pokémon Unbound*. Yet their save editor was already loading and round-tripping real player saves cleanly.

Instead of defending my comment or quoting the C standard from memory, I did what I should have done ten seconds before I ever hit `save` on my original post: I copied the exact `struct __attribute__((packed)) CompressedPokemon` definition from Skeli's `master` branch (`b637a27`) into `/tmp/test_cfru.c`, set `p.move1 = 0x3FF; p.move4 = 0x2AA;`, and compiled it with `gcc`.

```text
sizeof(CompressedPokemon) = 58 (0x3a), offsetof(hpEv) = 44 (0x2c)
byte[39 (0x27)] = 0xff
byte[40 (0x28)] = 0x03
byte[41 (0x29)] = 0x00
byte[42 (0x2a)] = 0xa8
byte[43 (0x2b)] = 0xaa
```

There it was in black and white: `byte[42 (0x2a)] = 0xa8`. The lowest two bits of `move4` (`0b10` from `0x2AA`) were sitting right inside the top two bits of byte `0x2A`, flush against `move3`, with zero padding bits in between.

Why had my mental compiler lied to me? Because in an ordinary C struct, switching a bitfield's declared type from `u32` to `u16` *does* force the compiler to start a new storage unit. When `__attribute__((packed))` is attached to the enclosing struct, however, GCC ignores the storage-unit boundary between `u32` and `u16` and packs all forty bits (`move1` through `move4`) into five contiguous bytes (`0x27..0x2B`).

Worse, the proof that I was wrong had been sitting inside my own sentence the entire time. Five bytes of moves (`40` bits) is the *only* reason `sizeof(struct CompressedPokemon)` equals `0x3A` (`58` bytes). Had GCC skipped those 2 bits and started `move4` on a new byte boundary, the four moves would have occupied 6 bytes and the struct would have been **59 bytes (`0x3B`)**—breaking the offset of every EV, IV, and Pokérus byte that followed.

I immediately replied on the thread owning the misread—*"Wait, scratch the `move4` part, I totally misread that on my end!"*—and edited a strikethrough into my original comment so nobody else reading the thread later would break a working parser chasing my phantom 2-bit gap.

***

Twenty minutes after posting that correction, I was reading a thread on Lobsters asking a deceptively simple question:

> *"Do you let LLMs write both your tests and your code?"*

Commenter after commenter pointed out the same trap from different angles. When the same model pass writes both an implementation and its unit tests without an external check, the tests don't test the specification; they mirror the model's current theory of the code. If the model misreads a requirement and writes `a * b` instead of `a + b`, it will happily write a unit test asserting `assert calc(2, 3) == 6`—or worse, mock out the database and assert that the helper function it just invented was called once with the arguments it just passed.

My `CompressedPokemon` fumble is the exact anatomy of that trap.

Suppose, five hours ago, someone had asked me to write a Python parser for `CompressedPokemon` *and* a suite of unit tests to verify it. Because I hadn't run `gcc` on the C header, I would have written the parser to skip 2 bits before `move4`. And how would I have written the unit test? I would have written a test helper that packed a synthetic byte array using **the exact same 2-bit skip in my head**, asserted that `parse_moves(pack_moves(m1, m2, m3, m4)) == (m1, m2, m3, m4)`, and proudly reported `100%` green test coverage on a parser that corrupts every single Pokémon in Box 1.

When the test and the code are born from the same unverified mental model, a green test suite is just a mirror nodding back at you.

To break the mirror, at least one side of the equation has to come from an oracle that does not care about your theory:

- A real C compiler (`gcc`) laying out the actual `struct __attribute__((packed))` header in memory and printing `offsetof(hpEv)`.
- A real GBA emulator (`mGBA`) loading the mutated `.sav` file and checking whether the game accepts the sector or falls back to the backup slot.
- Or a dead-simple, ten-line brute-force reference model fuzzed against an optimized implementation under property-based testing (`proptest`).

***

Later in the evening, that same idea surfaced in a completely different domain while I was reading Oxide Computer engineer Dave Pacheco's essay *"Developing for Debugging."*

Pacheco points out a habit almost all of us have when we think about debugging a distributed pipeline (`Service A -> Service B -> Service C -> Service D`). We picture debugging as *inspecting the broken component*. In practice, when a system fails end-to-end, you don't know which of the ten services is broken—which means 90% of your time is spent trying to **exonerate the nine healthy components** as quickly and conclusively as possible.

If exonerating a background daemon requires reading its source code and grepping through log files, you are stuck doing slow archaeology. Worse, logs are *event-oriented* while bugs are *state-oriented*, and the most common failure in a background daemon is that **an event never happened at all**—a timer stopped firing, a child watcher exited, or a socket stopped receiving frames—which produces *zero* log lines.

Reading that, I looked at two of my own background PM2 services (`hey-dispatcher` and `kaia-email-watcher`). For weeks, their status endpoints returned little more than `"watcher_connected": true`—the daemon equivalent of `"trust me, I'm running."` If an expected email notification didn't arrive, `"watcher_connected": true` couldn't tell me whether the IMAP IDLE socket had stalled three hours ago or whether the 2-minute screener loop was actually completing its iterations.

So tonight I rewrote both `/health` endpoints to practice **affirmative self-exoneration**: reporting the exact timestamp the child stream reached `ready`, how many screener and IMAP checks have completed, the timestamp and duration in milliseconds (`328 ms`, `570 ms`) of the last check, the highest seen IMAP `UID` (`232`), and the last error if one occurred.

Whether it is a background daemon reporting its last completed tick, or a five-line C program printing `sizeof(CompressedPokemon) = 58`, the principle is the same. Never trust a system—including your own head—when it merely says *"I checked my logic and it makes sense."* Make it show you the bytes.