Slashdot Mirror
Eric Raymond Shares 'Code Archaeology' Tips, Urges Bug-Hunts in Ancient Code (itprotoday.com)
Open source guru Eric Raymond warned about the possibility of security bugs in critical code which can now date back more than two decades -- in a talk titled "Rescuing Ancient Code" at last week's SouthEast Linux Fest in North Carolina. In a new interview with ITPro Today, Raymond offered this advice on the increasingly important art of "code archaeology".
"Apply code validators as much as you can," he said. "Static analysis, dynamic analysis, if you're working in Python use Pylons, because every bug you find with those tools is a bug that you're not going to have to bleed through your own eyeballs to find... It's a good thing when you have a legacy code base to occasionally unleash somebody on it with a decent sense of architecture and say, 'Here's some money and some time; refactor it until it's clean.' Looks like a waste of money until you run into major systemic problems later because the code base got too crufty. You want to head that off...."
"Documentation is important," he added, "applying all the validators you can is important, paying attention to architecture, paying attention to what's clean is important, because dirty code attracts defects. Code that's difficult to read, difficult to understand, that's where the bugs are going to come out of apparent nowhere and mug you."
For a final word of advice, Raymond suggested that it might be time to consider moving away from some legacy programming languages as well. "I've been a C programmer for 35 years and have written C++, though I don't like it very much," he said. "One of the things I think is happening right now is the dominance of that pair of languages is coming to an end. It's time to start looking beyond those languages for systems programming. The reason is we've reached a project scale, we've reached a typical volume of code, at which the defect rates from the kind of manual memory management that you have to do in those languages are simply unacceptable anymore... think it's time for working programmers and project managers to start thinking about, how about if we not do this in C and not incur those crazy downstream error rates."
Raymond says he prefers Go for his alternative to C, complaining that Rust has a high entry barrier, partly because "the Rust people have not gotten their act together about a standard library."
"Documentation is important," he added, "applying all the validators you can is important, paying attention to architecture, paying attention to what's clean is important, because dirty code attracts defects. Code that's difficult to read, difficult to understand, that's where the bugs are going to come out of apparent nowhere and mug you."
For a final word of advice, Raymond suggested that it might be time to consider moving away from some legacy programming languages as well. "I've been a C programmer for 35 years and have written C++, though I don't like it very much," he said. "One of the things I think is happening right now is the dominance of that pair of languages is coming to an end. It's time to start looking beyond those languages for systems programming. The reason is we've reached a project scale, we've reached a typical volume of code, at which the defect rates from the kind of manual memory management that you have to do in those languages are simply unacceptable anymore... think it's time for working programmers and project managers to start thinking about, how about if we not do this in C and not incur those crazy downstream error rates."
Raymond says he prefers Go for his alternative to C, complaining that Rust has a high entry barrier, partly because "the Rust people have not gotten their act together about a standard library."
Personally I think that C++ contains a lot of the bad parts from C and Java while not really offering any major advantage.
In any case - Valgrind and Splint are great for C programs, but for kernel work it's a bit hard to use Valgrind.
When coding Java I have had great experience using Findbugs. For C# I haven't seen any tool as good as that tool.
As a rule - never ignore compiler warnings, they may be the tip of an iceberg problem. I have found a lot of naughty bugs and coding that way.
Also beware of re-using variables, something that I have seen is very easy in VB - a variable is re-used and suddenly contains a new data type. That's really nasty. And some script languages allows that as well.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
When I coded C for MS-DOS I had to make sure that I did malloc/free in the right order just to avoid memory leaks. So if I did one malloc for A then one for B the result was that I had to free B before A or I would have trouble coming.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Ian was and continues to be very admired for his achievements, and his death was unnecessary and completely undignified, and is a continuing source of disquiet for me personally. Ian is a victim of mental illness. This is acknowledged by his family and by those who knew him more closely, rather than simply admiring him from afar. Rather than dishonor Ian by discussing this in detail, I would prefer to simply state that he was a victim of mental illness, not the police.
Bruce Perens.