Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Sunday August 08, 2004
06:30 PM

Open source and quality

[ #20305 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • There isn't a buffer overflow risk with using strcmp. The argv from main are always properly zero-terminated. They could be pretty large but that doesn't matter cause I don't see them being copied.

    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.

  • ...but not necessarily more secure in practice

    . 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 [].)

  • It's a nice thought. OS doesn't necessarily yield better programs, but better programmers.

    But the environment in which we develop software today vs. a few decades ago is different in more important ways than that. Just imagine not having that Internet thingy available. At all.

    No more googling for error messages, no FAQs, no quick answers to basic questions, no more interesting online discussion. Just you, alone in your cave, making the same mistakes as everyone else, only not knowing about it.

    In that env
  • Most of those active in the open source world, and many in the security world, believe this. However, the vast majority of people do not look at the source, and so you don't really have those many eyes. Even someone like me - technically competent, paranoid about security - doesn't really look hard at code. I rely on fora like bugtraq and full-disclosure, and lots of monitoring and logging, to alert me to security problems. If an app I want to use is buggy, I'm more likely to delete it and try something