On Wed, 2003-12-03 at 23:30, Henry Spencer wrote:

On Wed, 3 Dec 2003, Peter Hiscocks wrote:

...

This exploit, like others against Unix machines many years ago, was based on a buffer overflow dumping the user into supervisor space.

Actually, no, as I understand it (with the caveat that I haven't really gone investigating), this one is *not* a buffer overflow, exactly. It's the result of *integer* overflow in (essentially) a buffer-overflow check. A language with automatic buffer-overflow checks could easily have the same vulnerability, if the implementor wasn't careful.

Interesting, this is certainly a less common form of exploit...

...

After all, C is not so much a systems programming language as a high-level version of assembly language.

Oddly enough, it has pushed most "real" systems programming languages out of the business. And this is *not* because of sharp marketing tactics or firm backing by a big organization or dot-com hype -- quite the contrary. It succeeded because people with work to do find it easier to get results in C than in "real" systems programming languages, and so it spread and prospered despite inept or nonexistent marketing, uncertain support, and a marked dearth of hype.

It behooves people who aspire to design systems programming languages to *PAY* *ATTENTION* *DAMMIT*, rather than just casting aspersions on the intelligence and judgement of the customer. It is their own damn fault; their languages keep failing, and C keeps succeeding despite its nasty flaws, because they keep ignoring the needs of the real language users. People went with C because it did what they wanted, instead of telling them they shouldn't want that.

Honestly, I don't think there will be a language to supplant C as a *systems* programming language in general any time soon. Frankly, systems programming too frequently requires breaking the rules that other languages commonly enforce. There have been a lot of great languages developed out there for specific tasks. Perl is gorgeous for text processing, as is python I've heard. BASH is fair for simple task automation, and tolerable for slightly more complicated tasks. Matlab is a GODSEND for anyone doing algorithm prototyping and other kinds of scientific computation. Java is worlds beyond C++ when it comes to OOP. Hell, even Prolog and the many species of LISP-type-languages are interesting in their own right (though not terribly useful in my mind). The point though is that for applications where you need the kind of flexibility (or rope...heh) that C offers, there has yet to be any good substitutes. But if you fit well into a specific category of application development then there is a whole host of better choices for you. For instance, next major GUI application I write will probably be in Java or maybe C++ with a good widget library (GTKmm). It just hurts too much to write GUI apps in C.

...

Years ago, Philipe Khan of Borland said that 'C is a disease and the Americans are spreading it.' Maybe he had this kind of thing in mind.

I don't think it is impossible to keep C's virtues while eliminating its more grievous faults. But it will not be done by people who look down their long aristocratic noses at C, and scorn it as a peasant's language of no interest to them.

One mans grievous fault is another mans shiningly useful feature. Language wise I think there is really only a few things that can/should be done to improve C. Largely they involve incorporating the more sensible improvements from C++ and dropping most of the cruft. I.E. compile-time operator overloading would be nice but templates are horrendous. Beyond that though I think C would benefit most from more code reuse. Why is it that everyone has their own C libraries to handle strings? Things like Glib need to be more widely used, because otherwise we're all just reinventing the wheel and reproducing the bugs. -- Marcus Brubaker <marcus.brubaker-H217xnMUJC0sA/PxXw9srA at public.gmane.org> -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml