Xref: utzoo comp.lang.c:26608 comp.software-eng:3078 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!nic.MR.NET!jhereg!mark From: mark@Jhereg.Minnetech.MN.ORG (Mark H. Colburn) Newsgroups: comp.lang.c,comp.software-eng Subject: Re: C Community's Cavalier Attitude On Software Reliability Message-ID: <1990Mar6.034840.21620@Jhereg.Minnetech.MN.ORG> Date: 6 Mar 90 03:48:40 GMT References: <802@xyzzy.UUCP> <8230@hubcap.clemson.edu> Organization: Open Systems Architects, Inc., Mpls, MN Lines: 79 In article <8230@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From goudreau@larrybud.rtp.dg.com (Bob Goudreau): >> an application whose quality of >> implementation was lowered *solely due to the choice of C as the >> programming language*. > > 1) Unix. (Example: the problem in which the double-length password > was used by an intruder to bypass security, taking > advantage of C's lack of boundary checking) Ah, how quickly they forget. I would like to point out that Unix was heralded as one of the first (if not the first) operating system written in a high level language in order that it could be maintained more easily. This was a radical concept back in the days of handcoded assembly language operating systems. Unfortunately, there are still some companies out there such as Unisys and IBM that still code their major offerings in assembly language, making maintenance and upgrades very difficult indeed. The internet worm took advantage of a poorly designed peice of software which is NOT part of UNIX per se, but rather a library call. The library could have been written in any language. It happened to be written in C, but that is merely coincidental. Sure, you are about to say that if it were written in Pascal, which has stack/array bounds checking, the problem could not have occurred. But there you are wrong as well. Most Pascal compilers nowadays have flags which allow the stack/bounds checking to be turned off, and they usually are in distributed products (at least at the three companies that I worked for that coded in Pascal) because they incur too much overhead, thus slowing down the application. It is unfair to condemn an entire operating system for a single flaw by the way. I will admit that Unix is not flawless, but then, you can't find an operating system that is, so I'm not going to worry about it... > 2) AT&T's phone network (Example: recent crash, which was attributable > to C having switch/break instead of > a safer case statement) You can say that it is a problem with C, but there are other problems which can occur in other languages with the same devastating effects, for example misplaced semi-colons in Pascal, character reversal in Assembly language and just plain typo's. Most programming languages have some level at which they have to trust the programmer. Each language is different, but they all have their faults. C's is the power of the programming language, Ada's is the sheer bulk of the final code. ("What do you mean that it is going to take over 150 Megabytes of Virtual memory just to compile your code?", a question that I asked an individual who was requiring a machine reconfiguration on a network that I was administring.) > Now practically all programming languages are Turing-complete, so > anything which can be written correctly can theoretically be written > in any of them. However, some programming languages (e.g., C) are > more likely to leave errors undetected than others. Like I said, at some point you have to trust the programmer. If the programmer knows what they are doing, knows the language and is alert, 90% of the bugs would be caught during coding. However, programmers are human, and errors are made. That is life. It will be interesting to see the first time that a well publicized programming bug is discovered in an Ada application: here is a multi-million dollar language that was designed by commitee to assure "quality" software. Are you going to say that Ada programmers produce perfect code? If you are, I can produce some that will tell you exactly how wrong you are... -- Mark H. Colburn If you don't make money off of it, Open Systems Architects, Inc. it had better be either a religious mark@Minnetech.MN.ORG experience or a hobby. - Lance Cooper