07.28.09
How not to program a computer.
This one comes for the Qemu project. Let me first explain a little bit of the context.
- There are (at least) two current “official” qemu trees. One is called “upstream qemu”, and is where all qemu development happens, and there is the qemu-kvm tree, where kvm development mostly happens. I’m on a personal cruzade to end this.
- A lot of times, the kvm tree duplicate unnecessary state. In most of cases, this is because we implemented in kvm something that did not exist in Qemu before, but starts to exist in the future
- Qemu has something called “reset handlers” , that reset the state of a device upon reboots
Now, I was trying to get rid of duplicate state in the qemu-kvm tree. A cpu, in Qemu (and KVM) can be running, or stopped, and there is an intermediate state, in which a stop is requested, but we were not yet able to attend it. KVM had “stop” and “stopped” fields in CPU state. Now Qemu gained these same fields for other reasons, and I decided to, well, use them.
However, the cpu reset handler in qemu has the following masterpiece of defensive programming:
memset(env, 0, offsetof(CPUX86State, breakpoints));
What it does is: zero out all fields until the breakpoints field
As the stop and stopped fields are newly adds, nobody ever thought that it would have to be put AFTER the breakpoint field for it to work. There are so many ways this could go wrong, that I cannot even start telling it, but I’ll try:
- As it happened, we can add fields to that structure. This is not an on-disc structure, so it’s pretty common. The person adding that field may never had the chance to read this reset handler, and cannot imagine this pearl is there. It breaks
- This assumes that “resetting” means setting to zero for all fields up to this point. It might not be true in the future, and it breaks
- A person searching for weirdness involving a field in this structure will pass through this line with “This is breakpoint related” in mind, rather than “It is myfield related”, and will never figure his problem can be there
When we write programs, we should not aim to write the smaller line possible, the trickiest line possible, or any of these. We should aim for writting the dumber and more obvious line possible, so anyone that has at least half of a brain can read this and say exactly “this is what it does”
And to my readers, featuring next week: I’m finishing my long waited text “10 reasons to use Linux - Not necessarily GNU/Linux”. I might change the number of reasons, tough ;-)
Popularity: 51% [?]
