teaching debugging

westfw:
And you have to look. And try. Or you get bugs like apple's recent embarassment:

Things like this are good exercises for newbies. (And the rest of us for that matter.) When presented in a forum like this, it becomes a kind of game to figure out the bug. For example, at least taken out of context, I see a few potential flaws in this...

  1. Several variables aren't defined. Now, they're probably defined in the "..." but then again maybe they're not. After all, we see one variable defined, then a snip, then code. Attention to detail would reveal that hashCtx, serverRandom, hashOut, and signedHashes weren't parameters and weren't defined. Are they global? Obviously the code wouldn't even compile if they weren't defined at all, making it unlikely this bug would make it into the wild, unless distributed as source rather than a compiled executable. But a good developer should be asking him/herself these questions regardless.

  2. What's UInt16? (I could be showing my ignorance here.) How's that different from the actual C99 type uint16_t? Was that a typo? (Again, it would fail to compile if it were actually mistake.)

  3. While not necessarily indicative of a problem, every developer should be suspicious of those pointers, custom types lacking pointers, and address-of operators. It's such a common source of errors that it should be reflex to examine them, even if compiler warnings are turned on and "should" complain if they don't match up.

  4. Obviously (and the point of this snippet, I'm sure) is the fact that there are two "goto fail;" statements after a conditional. The second is indented like it's supposed to be executed after the second conditional fails, but without block braces, the compiler will treat it as a statement that will be executed as a matter of course after passing the first two conditionals.