OK, you have an excellent point, Henry, that people have chosen C for good reasons. I actually was on the receiving end of this kind of academic scorn at one point. I had developed a computer controlled sound system for use in the theatre, and this being 1982 or so, I had to use what was available, the Commodore PET. The system was written in a combination of Commodore Basic and 6502 assembly language. I was at a party of comp sci academics and one of the profs - a guy who specialized in human interfaces - expressed some interest in the system. When he heard that the system was programmed in basic he turned to his neighbour and said 'We have to stop these people from programming in basic'. and then walked away. The system was used in a number of shows in Toronto and then the concept was adopted by another company and made into a successful product. At the time, I thought of your point: people liked those Basic languages (which does have some appalling shortcomings as a language) for a number of good reasons - they were a friendly development environment, and easy to interface to assembly language. Furthermore, you couldn't get any other language for the Commodore PET. A competent engineer works with what they have available. Incidentally, a modern version of Basic is Tcl/Tk, which has many of the same properties that made Basic popular. So, it is an interesting challenge to the language writers to create something that has the power of the C language and still does (say) automatic checking of array bounds. Peter On Wed, Dec 03, 2003 at 11:30:28PM -0500, 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.
This, in turn, is a direct result of the fact that the C programming language does not check or enforce limits on a string length or buffer size - that's left up to the individual programmer.
As has often been said, C gives you all the rope you need to hang yourself.
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.
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.
Henry Spencer henry-lqW1N6Cllo0sV2N9l4h3zg 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
-- Peter D. Hiscocks Department of Electrical and Computer Engineering Ryerson University, 350 Victoria Street, Toronto, Ontario, M5B 2K3, Canada Phone: (416) 979-5000 Ext 6109 Fax: (416) 979-5280 Email: phiscock-g851W1bGYuGnS0EtXVNi6w at public.gmane.org URL: http://www.ee.ryerson.ca/~phiscock -- 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