Why bad food is sometimes good

WARNING: Extreme Geek Alert!

I've been working through a weird issue with the database engine - sometimes, when trying to read a blob, I'd get a debug assertion, indicating that a condition that should never happen has happened. After looking it over for most of today, I found that the file number of the file it's trying to read from was 61453. I assumed that this was just some garbage semi-random value, but the more I looked at it, I realized that it was exactly the same value every time. Repeatability in debugging is a very good thing. On a whim, I converted this value to hex: 0xf00d.

When Windows allocates memory, it fills the memory buffer with the hex values 0xbaadf00d, so that it's obvious that this memory has been allocated but not yet used. The fact that this value was 0xf00d was a strong indication that the value was simply never set. A few more minutes of debugging and I found the problem.

Say all the nasty things about Windows that you want, but it would have taken a lot longer to find this problem on Unix. Unix doesn't fill allocated memory with anything, so if I were to run the same test there, sometimes it would work, sometimes it wouldn't, and the repeatability would be much lower, thereby making the problem harder to solve.

\/\/ind0wz r00lz!!!!1!!1!1!

(Not really, I just put that there for John-the-Mac-boy's benefit.)