Today's been an interesting day on many levels. I've finished some more work for an online class I was taking, immediately started using some of the knowledge gained in the current class to automate a rebuilding process for a software package I've been debugging and when I was done, submitted a small patch to the Debian folks for the unmaintained bblaunch software. Not only do I find it fascinating how many things have worked together to produce a single result, but in reading through the C code, I was struck at how differently I would probably have coded some of it than from what the original author did. For example, I see plenty of things like this:
if ((!strcmp(argv[i], "-s")) || (!strcmp(argv[i], "--shaded"))) {
valargs = 1;
launchargs.flags |= (1l << 0);
launchargs.attrib |= (1l << 0);
}
else if ((!strcmp(argv[i], "-h")) || (!strcmp(argv[i], "--maxhoriz"))) {
valargs = 1;
launchargs.flags |= (1l << 1);
launchargs.attrib |= (1l << 1);
}
else if ...
Not only do we have duplicate code (and plenty more than this), but we also have a potential buffer overflow in strcmp(). Those checks should using strncmp() instead in order to limit how many characters would be compared. (To be fair, my C is bad enough that I probably could not have written this software, so after-the-fact critique is a bit cheeky.)
Now given that anyone who reads my journal knows that my C skills are pretty poor, it might seem a bit surprising that I noticed these things (I'm sure that there is plenty more that I didn't notice.) I don't think it is that surprising, though. I noticed it because open source software is one of the greatest boons to software development. I have literally worked on software written before I was born (1967, if you must know) and it was atrocious. Now, not only has general software knowledge advanced, but our ability to disseminate that knowledge has advanced. Thus, even run-of-the-mill developers like myself can speak confidently about refactoring, defensive programming, decoupling, and other software concepts that, while they were certainly known a few decades ago, were far less likely to be employed. In our open-source world, we routinely get top-notch developers teaching new programmers how to be better. This is a level of teaching that would have been unheard of a few decades ago. We don't know how lucky we are.
I keep hearing debates about whether or not open source software is better quality. Given that it's difficult to check the quality of closed source code, I think this is a fruitless debate. However, the one benefit of open source that is tough to deny is this dissemination of information. Any beginning programmer can search through code and learn new techniques. Rather than read about abstraction in a dry textbook, we can see it being applied in real, live programs. We can also read online bits like this drivel and pick up even more. Closed source cannot offer that.
Economics teaches us that information acquisition has a cost and higher information costs (sometimes called "search costs") cost results in suboptimal results. Programmers should learn this, too. The lower the search costs, the better the results.
Also, the risk with strcmp with a big buffer is a segfault. There is no writing going on so there is no buffer overflow danger.
. Economic theory suggests that, at least to first order effects, the ease of searching for problems in open source code offsets the improved quality making the practical security equivalent. (However other bugs are less.)
For details, see Security in Open versus Closed Systems - the Dance of Boltzmann, Coase and Moore. (From Economics and Security Resource Page.)
I read a paper recently (sorry, I forget who by, what it was called, or where it was published, but it was a reputable journal) which basically said that it didn't make much difference to the bugginess of a major release whether software was closed source or open source. But it then went on to say that open source developers tended to fix their bugs quicker once they were reported.