A bad memory from the past has resurfaced: In response to my post Friday about national security dangers from intentionally buggy source code, a reader suggested that the problem was in today’s programming languages, such as C; FORTH, he argued, was a simpler language and therefore helps programmers make better systems. Well, FORTH sure is simpler in some ways, but I had to work in it for two and a half years, and it was pretty lousy. Maybe it’s vastly improved now, but I highly doubt it.
In fact, of all the languages that I know — I worked as a programmer full-time or part-time for 12 years, made money working with BASIC, some C, a tiny bit of COBOL, FORTH, FORTRAN, LISP, PASCAL, and SPL (an HP 3000-only language), and also played some with APL — I think C is probably my favorite. (I coded in C before C++ got big, so I can’t speak about C++, but from what I hear of it, I think I’d like it, too.) C has plenty of problems: Just as PASCAL (or at least the 1980s versions that I used) is too rigidly typed and straitjackets the programmer too much, the 1980s versions of C were too loosely typed, and didn’t give the programmer enough help with avoiding the errors that even the best programmers make. Still, it seems to have fewer problems than any of the other languages I’ve used.
In any case, while I haven’t really worked in the modern computer industry, I highly doubt that the potential security vulnerability caused by “software warfare” really stem from the computer languages people use. Choice of language can make a considerable difference — I just don’t think it’s what’s making the difference here.
UPDATE: Just to clarify, I’m speaking here of security problems caused by people intentionally planting bad code in various broadly used products, whether it’s a programmer putting some backdoor or bomb into Windows, or a terrorist- or foreign-power-controlled company distributing its own products that have international problems in them.
Accidental security holes that hackers can then exploit might indeed be caused in part by language problems — some languages make it somewhat harder for certain bugs to accidentally happen, while others make it somewhat easier. C, for instance, is a language that generally doesn’t do much type checking or bounds checking, which makes certain kinds of bugs (such as buffer overflows) more likely. (There may well be specific versions that don’t suffer as much from it, but this is what standard C was like in the late 1980s, when I was exposed to it, and how I understand it still mostly is today.) FORTH, incidentally, is if anything actually worse than C in these respects. PASCAL and some other such languages do much more type-checking and bounds-checking — way too much, in my book, because they also make it much harder for programmers to do correct and useful things. I suspect one reason that C prevailed over PASCAL is that PASCAL shackles people too much.
My preference has always been for languages that do lots of type-checking, bounds-checking, and other such checking for constructs that may be evidence of bugs — but that also make it easy for the programmer to waive, on a case by case basis, this checking (for instance, by providing a means of easily telling the compiler that an object of one type should actually be treated as having a different type). Unfortunately, my preferences have a way of hardly ever getting turned into industry standards, even when I’m quite positive that I am entirely right.
In any case, though, this is a tangent (prompted by a helpful message from reading Andrew Myers’ response to an earlier version of my post). My basic point was about vulnerability to intentional bombs or backdoors created by rogue programmers, often in code whose source code is never checked by anyone (or checked at most very lightly). And I do think that this concern is largely (though I’m sure not entirely) independent of the languages being used, precisely because the source code, in whatever language, is not checked.
Comments are closed.