Queue cleanup

[Paul Rubin]

Lawrence D'Oliveiro <ldo at geek-central.gen.new_zealand> writes:
> That reinforces my point, about how easy it was to check the correctness of 
> the code. In this case one simple fix, like this ...
> would render the code watertight. See how easy it is?

Well, no, it's irrelevant how easy it is to fix the issue after it's
pointed out.  What matters is how easy it was to create it in the first
place.  You posted a 30-line code sample as obviously free of memory
leaks, but even a good programmer like you didn't notice that it had the
potential for a nasty memory overwrite error after an unbalanced decref.
Keep in mind that a memory leak usually just means the program can
eventually bog down and stops working, but an overwrite error is often a
security hole that can lead to total compromise of your entire computer.
Now extrapolate that error rate from 30 lines to a program the size of
Firefox (something like 5 MLOC), and you should see how fraught with
danger that style of programming is.  Even the most skilled and careful
programmers are going to slip up once in a while.

Part of the problem is C itself.  No language can eliminate many
complicated bugs without creating severe usability problems, but good
languages (unlike C) can eliminate most "silly" bugs.  I had a "dark
night of the soul" after reading some of the bug-finding papers at

  http://www.stanford.edu/~engler/

and have been terrified of C ever since.  I'm just always skeptical when
anyone says they're sure any piece of C code is obviously bug-free.
It's quite easy to get overconfident about it (as I've done myself more
than once).  I spent about 5 minutes reviewing your patched code (and
the underlying implementations of the C API functions it calls) and
didn't see any other issues, and the code is probably ok now, but I'd
have to spend a lot more time tracing through the API layer before I
could be really sure.

Anyway, you should check your patch into github if you haven't.