Lawrence D'Oliveiro <l...@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. -- http://mail.python.org/mailman/listinfo/python-list