I got a reply from Jeff today about his C/C++ article. My comments are at the end

From: Jeff Duntemann (jduntemann - @ - copperwood.com)
To: Acidus (acidus@yak.net)
Date: Tue, 9 Nov 2004 09:50:57 -0700
Subject: Re: C/C++ responsible for Buffer Overflows

Billy--

Thanks for writing. The kicker isn't the C language per se--when I write C it looks (and works) pretty much like Pascal, which everybody in the C world seems to hate. The real problem lies in two areas:

1. The C "I can do anything I want or I'll hold my breath until I turn purple!" culture. Getting C programmers to adhere to coding standards is pure hell.

2. The standard C library. There's no real reason to use the string functions as they currently exist. There are numerous other functions (and rewrites of the canonican C string functions) that have built-in protections against overflows, e.g. strncpy(), strncmp(), and snprint(). My favorite is:

size_t strlcpy (char *dst, const char *src, size_t size);

This isn't part of standard clib, but if people used it, we'd see a LOT less of this sort of thing. The fact that people DON'T use it tells me that down on the front lines, programmers really don't care about buffer overflows. This is the C culture again. I'd really like to see a total rewrite of clib, with an eye toward preventing what we now know of hacker exploits. The damned thing is what, 25 years old now? I think it's way past time for an overhaul. But when I suggest it, you'd think I was saying we should torture newborn kittens. The truth is that C and clib are inseparable in the current C culture. To me, that means that we have to dump both.

I agree that an executable stack is a bad idea--but it's easier to change CLIB than to make a major change in existing hardware. Since we're unlikely to be able to change clib, I've been pushing for managed languages like Java and C#.

Lots of things to do today so I'll have to stop here. Again, thanks for writing and good luck.

--73--

--JD--

While I agree that programmers will always make mistakes, there is a balance between smart languages and smart people. I choose requiring smart people every day, because besides performance issues, a language that is too smart can prevent an experienced coder from doing what they need to do. By Jeff's logic, a seg fault is the languages fault, because the language didn't prevent it. Some languages, such as Java and C++ allows for users to catch and handle errors, which is a nice compromise to an all out smart language. If you compile a C program using gets(), you will get a warning, telling you to use fgets(). In the same way, the compiler could warn about "dangerous" string functions. Organizations can put rules into their make and build commands, refusing to let them go into production code. The point is their are other options them simply saying "this is a bad language." Its not bad, its just not being used/managed in an intelligent fashion.