On 2005-09-17, Jerrold Leichter wrote (without retaining attributions): >>>> So wouldn't the world be a better place if we could all agree on a >>>> single such library? Or at least, a single API. Like the STL is for C++. >>> >>> Yes, absolutely, but who is going to do it? >> >> One could argue it has already been done.
It (the creation of such a library) has been done many times; admittedly, widespread adoption has not happened at all. >> There exists a widely available, freely available, well-implemented >> example of something just like the STL for C++. It is called >> "the STL for C++". >> >> a) Writing in C++ is easier than writing in C. Only for people who find it easier to use a huge clunky tool they will never fully know than a clean simple language which can be used to write completely reliable software. Of course, C's simplicity is its danger: any idiot who can spend a few hours with a C for Dummies kind of book can imagine that he's competent to write in C. As with any sharp tool, careful use is mandatory to avoid nasty cuts; thorough understanding is needed to ensure safe handling. We don't expect people to fly commercial aircraft without taking the time to become suitably skilled. We don't expect people to start doing brain surgery without having appropriate training. Software is complex stuff; it takes time to acquire skills with it. For those with the skills, C is an excellent tool. It's not perfect, but it's the best thing we have and it's well able to do the things we ask of it. The problem is bad programmers. >> b) Porting legacy C to C++ isn't rocket surgery. It can be done >> incrementally. > > And the STL is safer than C ... in what sense? STL iterators are modeled on C > pointers - warts and all. An STL iterator can point to random memory just as > easily as a C pointer. An indexing operation into an STL vector or similar > data structure is subject to exactly as much range checking as a C indexing > operation. > > Yes, there exist implementations of the STL that check such things - just as > there exist implementations of C that check such things. None appear to be > widely used. And, of course, while no standard *forbids* such checks, none > *require* them, so (a) availability is spotty; (b) compilers typically contain > no optimizations aimed at making such things efficient. Agreed, the STL (and C++) is no answer. > RISKS had a large number of messages on this topic back in 2002. I wrote one > long commentary (in RISKS 21.85 - see http://catless.ncl.ac.uk/Risks/21.85 for > one on-line source) that I stand by to this day. Very little has changed. While you make some valid points in that article, I take issue with much of it. For instance, you cite "[a] large body of code that provides bad examples" as one of the big faults with C. This is just not a valid argument. (Yes it's true: there is such a body of code, but it's not an argument.) The classic book of examples of bad programming, "The Elements of Programming Style" by Kernighan and Plauger, dates back to the days before C. Its examples are in Fortran and PL/1. It is full of the same kind of blunders we are talking about here. It's not the language, it's the programmers who are at fault. The only reason that we see much in C is that, for the past 25 years, most widely-seen software has been written in C. > (Actually, there has been a *bit* of improvement: Microsoft submitted a > proposal for a set of new string - and related - functions for standardization > in the C library. They differ from the classic functions in always having an > explicit output buffer length. Personally, I find the particular API typical > of Microsoft - butt-ugly and a pain to use - and I *think* that the standards > groups may be re-working them. But one way or another, after all these years, > we may eventually have safe alternatives - once we work throught the > standardization process and get the stuff out there (I'd guess another 2 years > at least before you can safely assume that it'll be available). I haven't followed any news about that. Anything that comes out of Microsoft won't be worth considering -- nothing from there has been good in the past, so there's no reason to think that might change. More to the point, it takes many years before stuff like that becomes widely available (and therefore usable). We don't need new tools; we just to learn to use the ones we have effectively. The comments you make about seat belt and air bags don't make much sense either. Their purpose is to save our lives after we have made a potentially fatal mistake. After all, there's a big mess to clean up when those things are used, so it's not like we want them to play an active part. This is also a question of culture. Everybody thinks they have the right to drive but no responsibility to learn how to do it well. So, since bad driving causes so many deaths, governments mandate all sorts of after-the-accident safety gadgets. If they mandated proper skill and attitude training before allowing people to drive, we'd save a lot more lives. Equally, if the software community started to expect suitable training and skills in programmers, we'd solve most of our current problems. To return to the original point. Every serious C programmer who cares about his work has known forever that the C standard library serves only as a basic low-level building block for use in creation of real libraries that suit the project at hand. It also contains a few simple functions, like gets() and the other maligned string-handling functions, that serve as quick and dirty gadgets for programmers to use when writing a quick bit of test code for their own use where security and safety are not at all important, but checking something else quickly is the goal. I have written C code that has been running daily in commercial environments for over 20 years that has never had a failure, as a result of buffer overflows or any other bugs. I'm not unique. But I do see lots of people writing C who seem to think that they have the right to do it as badly as they like, even though they know you have to be properly qualified to work in other fields. Greg --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]