Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!mintaka!mit-eddie!rutgers!att!cbnewsh!rkl
From: rkl@cbnewsh.ATT.COM (kevin.laux)
Newsgroups: comp.lang.c
Subject: Re: problems/risks due to programming language
Message-ID: <8407@cbnewsh.ATT.COM>
Date: 22 Feb 90 16:59:13 GMT
References: <201@puma.ge.com> <8111@hubcap.clemson.edu>
Organization: AT&T Bell Laboratories
Lines: 54

In article <8111@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:
| From jnixon@andrew.ATL.GE.COM (John F Nixon):
| >>   This is not a valid analogy.  In C, the case statement *requires* the
| >>   use of a restricted GOTO in order to accomplish "normal" processing;
| > 
| > But we aren't talking about using the "break" in this sense, we are talking
| > about using the "break" to exit an "if", something which isn't C.
| 
|    We are talking about using a restricted GOTO to exit a control structure
|    in a normal situation.  The fact that one type of C control structure
|    requires use of a GOTO for normal exit and another type of C control
|    structure does not is a source of inconsistency and potential confusion.
|    
| >> In other words, C requires use [of] a dangerous construct on a routine basis.
| > 
| > Just as Ada requires the use of "exit" to leave the "loop" construct;
| > unless you use Ada'a "goto"...
| 
|    Not true; the bare "loop...end loop" is used in situations in which 
|    the intention is for the loop to execute forever.  This arises in
|    embedded controllers, operating systems, and similar applications.  
|    If one is not writing such applications, then "while (Condition) loop"
|    and "for Control_Variable in Start..Finish loop" are normally applied. 
| 
|    By requiring the use of a GOTO during normal processing (as C does
|    with its switch..break system), C encourages its programmers to get 
|    into the habit of using its restricted GOTO routinely.  As AT&T has
|    recently discovered, that can easily prove to be an expensive habit. 

	For some reason this is starting to annoy me.  All this talk about
'dangerous' GOTOs, restricted GOTOs, etc.  The bottom line is that the
program was coded *wrong*, whatever the language used.  Reminds me of the
phrase "the program should do what I wanted, not what I told it...".

	Anyway, as for the stigma of using GOTOs, way back when, I fell for
the line of bull about GOTOless programming.  I changed my mind real quick
for two reasons:  1) when I found myself in a situation where I *had* to use
a GOTO (break all the way out from inside of two loops) and 2) when I looked
at the assembly language generated by the compiler.  Turns out that when
an IF is employed, the compiler will often generate a test that is the
of the reverse sense and will then perform a conditional branch (gee, a
restricted GOTO).

	So, if you take a look at the machine language generated by your
C program, you'll find it littered with lots of conditional and unconditional
jumps.  The difference we're talking about is the *explicit* use of jumps
by the programmer (and not the implicit ones hidden by the language).

	GOTOs are not inherently dangerous contructs.  *Abuse* of them is.
Lastly I don't find that fact that one C control structure requires a GOTO
(via break) for 'normal' exit versus one that does not to be any source of
confusion.  SWITCH..BREAK is very well documented.

--rkl