Acidus wrote:
] 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.

I don't know the backstory here, but frankly I agree with his point about having to maintain the "backwards compatibility" in regards not only to the code, but the mindset of the old skool programmers. I am not justifying bad code by any means, just acknowledging the point that it is difficult to teach and old dog new tricks.

You are aboslutely right in terms of teaching programmers to use proper and secure coding standards, whcih is somethign I push myself. It just isnt realistic. The "old" programmers simply dont care. It is being taught to the "new" programmers and it will simly take a generation (not an AGE generation, but a programming generation of about 5-10 years) to get this mindset to cycle through so that the majority of users adhere to it.

Until then, it is up to us to help out by teaching proper coding techniques to the young ones and to particpate in projects with the older ones and correct their code until it sinks in.

RE: Jeff Duntemann responds to my email