Software Reliability: Don't Use the Wrong Tools

C is not the cause of the bugs - the cause is the weenies that think they know how to write software after they learn C.

That's like saying that the old table saw that's missing the finger guard isn't responsible for cutting off the owner's fingers, it's the owner's fault. Yes, it *is* the owners fault, but mainly for keeping and using a broken tool that is prone to such problems

Sure, the programmer has responsibility for bugs and security holes in his code. But when you use a stupid language that don't provide even the most trivial of protection from stupid buffer overrun problems, I'd have to conclude that the language is at fault as well. So the programmer should be blamed not just for writing bad code, but also for choosing poor tools.

Some people think that it's a good thing to use compilers that generate no run-time error checking (for array bounds and such), because it's more efficient. When given a language or compiler that can support run-time error checking, they may use it for debug then disable it for production. That's like practicing the use of life preservers on solid ground, then leaving them behind when you set out to sea, because they're too heavy.

So maybe the C language isn't to blame for software security problems, just as the broken table saw isn't to blame for cutting off fingers. But just as any sensible workman would fix or replace the broken table saw rather than continuing to use it and risking losing fingers, programmers should fix or replace the C language, or we'll keep having these software security problems.

It's possible to write bad code in any programming language. But there's no excuse for using tools that don't try to catch the most obvious bugs, or for using languages that are so poorly designed that such problems can't be detected by the tools.

There are plenty of programming languages out there that don't have these problems. Some of them are just as efficient as C for all practical intents and purposes.

Eric

In some cases I have purposely removed the finger guard and still have all 10 fingers. I'm not stupid enough to put my fingers near the blade.

That's exactly my point. If you sell table saws with no finger guards to experts, they *usually* won't cut their fingers off. It will happen occasionally. If you sell them to the vast unwashed masses, it's going to happen frequently. So a vendor selling table saws with no finger guards is considered to be somewhat irresponsible, even though it's the end user that is really at fault.

Similarly, you can expect that expert C programmers will usually write appropriate bounds checking, while the unwashed masses of C programmers will not. Guess which group writes the majority of code? Given that, are you really willing to claim that C is not a problem?

It's been known since the 1960s that there are certain classes of common errors that programmers make, and that it is possible to design languages such that many of them are caught at compile time. It is really a crock that brain-damaged languages like C and C++ became the standards in the 1980s and 1990s.

Computers are supposed to be labor-saving devices. Since it is entirely possible and even easy to design a programming language that can support bounds checking, how can anyone maintain that it is a good idea to use a language that can't, and thus shift that burden onto the programmer?

Note that I'm not criticizing C when used as was originally intended, for systems programming hosted on and targeted to small computers. But it's completely inappropriate for modern systems. Even when developing for small embedded systems, the development is normally hosted on machines with plenty of memory and CPU cycles, on which using a cross-compiler for a reasonable language is entirely feasible.

CBFalconer wrote:

C's fundamental insecurities are in pointers and context sensitive use of symbols. Also, some of C's fundamental efficiencies are in pointers.

Steve O'Hara-Smith wrote:

This hits the nail fairly and squarely on the head, like most tools the benefits and the risks stem from the same feature.

jmfbah wrote:

Exactly. Thus you don't remove the feature just because somebody can turn it into a bug.

When you buy a power saw, it comes with a finger guard. I'm not sure whether there are any laws or regulations that require this, but the manufacturers know that if they leave it out and someone saws off his finger, they'll be sued. (Of course, they may be sued even though the finger guard was present, but at least they'll be able to demonstrate to the court that they exercised due dilligence in trying to minimize the danger to the user.)

Expert users may remove the finger guard. Sometimes the finger guard gets in the way, and an expert can get his job done more quickly and easily without it. And the expert *usually* won't saw off his finger. But you don't see the experts telling the manufacturers to leave the finger guards off the product as sold.

Most people I know only remove the finger guard temporarily when it is particularly causing trouble, and put it back afterward because they recognize that most of the time it is a valuable safety feature.

C is the power saw with no finger guard. C was designed such that not only does it not come with a finger guard, but it's extremely difficult to bolt one on. C doesn't even provide a good place to attach a label "Warning: watch your fingers".

I don't think anyone in this discussion is proposing that computer languages shouldn't let you do anything you want if you're willing to indicate that you REALLY do want to do it. A power saw that was physically incapable of sawing off fingers would probably be of no use for anything. But sensible programmers (IMNSHO) will use tools that can catch stupid mistakes rather than assuming by default that you really did want to saw your fingers off.

C isn't a power saw, it's a saw blade. The problem is, everyone expects you to buy the blade, motor, frame, and bench, and put it together yourself, and the guard costs at least as much as all the rest of the stuff put together.

There are examples in the literature of catastrophic system failure in automated flight systems from both unhandled exceptions and inappropriate exception handlers.

But there are examples (and not just one or two, tens or hundreds on each machine) on practically every non-embedded computer in existence (and probably very many embedded ones - I'm about to upgrade the firmware on my phone for the second time in 6 months because it keeps randomly dying) of severe security vulnerabilities due to undetected overflows of various kinds. Billions and billions of dollars are wasted every year on this crap that should just never happen. And yes, in many cases a default exception handler of `oops, overflow, I will stop' is a *lot* better than `I will just silently grant access to the machine because I don't even bother detecting the overflow, let alone have an exception handling system worth the name. And yes, of course you can write safe software in languages with no checks: you can write all your code in hex too, and the reasons why people don't do either are the same, it turns out.

Everyone loves to quote Ariane, or software that runs nuclear power stations, but somehow no one bothers to mention IE, or sendmail, or ssh, or the Linux kernel.

Back to Eric's home page

Last updated 10-Jun-2003

Copyright 2003 Eric Smith

eric@brouhaha.com

check now