Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!udccvax1!mccalpin From: mccalpin@vax1.acs.udel.EDU (John D Mccalpin) Newsgroups: comp.lang.misc Subject: Re: problems/risks due to programming language, stories requested Message-ID: <5794@udccvax1.acs.udel.EDU> Date: 28 Feb 90 19:17:44 GMT References: <9790@medusa.cs.purdue.edu> Reply-To: mccalpin@vax1.acs.udel.EDU (John D Mccalpin) Organization: College of Marine Studies, Univ. of Delaware Lines: 38 In article bill@ssd.harris.com (Bill Leonard) writes: >In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes: > I received the following on AT&T's famous bug (and have deleted multiple > forwarding headers): > | | In the switching software (written in C), there was a long > | | "do . . . while" construct, which contained > | | a "switch" statement, which contained > | | an "if" clause, which contained a > | | "break," which was intended for > | | the "if" clause, but instead broke from > | | the "switch" statement. > Again it looks like this bug wouldn't have occurred in another > programming language. >I can't resist saying that this last statement seems to me to be utter >nonsense. What programming language (read, compiler) can read the >programmer's mind and tell what he meant? The problem of course is that the language allows unmarked branches. If the language forced all "goto-like" structures to have alphanumeric labels then this error could not have occurred in the way that it did. Obviously, if the programmer gives the wrong branch target then the compiler cannot help. On the other hand, the language should probably use different keywords for "breaking" out of each kind of flow-control structure, so that the programmer would have to not only give the wrong label, s/he would also have to give a label that was in use in a structure of the same type. This type of error should be far easier for the reviewers to identify since it is then an obviously incorrect branch. >Use of an inappropriate language is no excuse for abandoning other techniques >of good software engineering. >Bill Leonard Yup.... But that is certainly not a justification of the use of programming languages that allow such errors to occur without any justifying increase in power or clarity.... -- John D. McCalpin - mccalpin@vax1.acs.udel.edu mccalpin@delocn.udel.edu mccalpin@scri1.scri.fsu.edu