C considered harmful

[Peter Hiscocks]

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