Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!labrea!aurora!ames!ptsfa!ihnp4!inuxc!iuvax!pur-ee!j.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c
Subject: Re: goto's in C: an opinion...
Message-ID: <556@l.cc.purdue.edu>
Date: Fri, 24-Jul-87 10:24:53 EDT
Article-I.D.: l.556
Posted: Fri Jul 24 10:24:53 1987
Date-Received: Sat, 25-Jul-87 17:48:38 EDT
References: <3289@bigburd.PRC.Unisys.COM> <7571@beta.UUCP> <4437@jade.BERKELEY.EDU>
Organization: Purdue University Statistics Department
Lines: 42
Summary: goto's are useful and may be the easiest to understand


I have actual subroutines which, inside the main loop, have code such as

	.....
mod:	.....
	.....
	if(....)goto terma;
	....
	if(...)goto termb;
	...
	if(......)goto termc;
h:	....
	if(.....)goto terma;
	....
	goto h;
terma:	......;
	goto mod;
termb;  ....;
	goto merge;
termc;	....;
merge:	....; goto finish;
termd:  ....;
finish: ....;}

as well as other goto's internally in the code.  The goto h could be replaced
by a while() statement, but would be no more readable.  I see no remotely
reasonable way to replace the other goto's without both slowing the code and
decreasing readability.

	I know goto's can be dangerous, but I do not call a tank to drive
me to work.  As far as proving the correctness of a program, this program is
actually fairly short, and each part is implementing a case in a rather
intricate procedure which does a lot of branching from case to case until
a termination condition is attained.  If the C compiler on the VAX could be
persuaded to use all the registers, no non-explicit memory references would
be used.  Clarity of code is not achieved by not allowing the programmer to
do what is natural, and there is nothing unnatural about goto's except in the
minds of the ignorant or totalitarian :-).
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu or pur-ee!stat-l!cik or hrubin@purccvm.bitnet