[comp.lang.c] goto in C

ok@quintus.UUCP (Richard A. O'Keefe) (03/08/88)

In article <25348@cca.CCA.COM>, g-rh@cca.CCA.COM (Richard Harter) writes:
> Currently I average about one goto per 10,000 lines of code, all of them
> being transfers to a procedure epilog, e.g
> 
> foobaz() {
>   ....
>   allocate space and other setup
>   ....
>   if (some_special_condition) goto wrapup;
>   ....
> wrapup:
>   deallocate space and other cleanup
>   }
> 
> But do people actually use it to any signifigant extent?  Why not just
> drop it?
> -- 

I very often write code of the form

sometype foo()
    {
	int state = 0;

	<side effect 1>	/* open file, or allocate memory */
	state = 1;
	<side effect 2>	/* same sort of thing */
	...
	state = N;
	<return new object>
    ERROR:	
	switch (state) {
	    case N:	/* undo side effect N */
			/* falls through to */
	    case N-1:   ...


	    case 1:	/* undo side effect 1 */
	    case 0:	/* return error code */
	}
    }

If you are trying to write code that other people can use,
it really isn't good manners to lose chunks of memory just
because you couldn't open a file.  One of these per library
package, and one per program, doesn't seem excessive.

This is a sufficiently stylised approach that it could be replaced by
some other mechanism.  (Nested exception handlers?  C++ destructors?
unwind-protect?)  But in a language like C, why not just keep the goto?
{Actually, a break-from-labelled-statement would work too, but that's
just another goto.}

There's another reason for retaining the goto.  Look at the output of
YACC some time.  I counted five labels in yyparse(), but may have
missed some.  It isn't just people who write C, you know!  Why shouldn't
people be allowed to write compilers which generate C?

g-rh@cca.CCA.COM (Richard Harter) (03/08/88)

In article <740@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>I very often write code of the form
>
	[Elegant stylised error handling mechanism example deleted.]

Pretty.  I am going to have to think about that.

>If you are trying to write code that other people can use,
>it really isn't good manners to lose chunks of memory just
>because you couldn't open a file.  One of these per library
>package, and one per program, doesn't seem excessive.

	Not good manners is a weak term -- particularly in code which
is designed to run as a background process indefinitely.  The inadequacies
of malloc and C memory allocation is a topic for another time. 

>This is a sufficiently stylised approach that it could be replaced by
>some other mechanism.  (Nested exception handlers?  C++ destructors?
>unwind-protect?)  But in a language like C, why not just keep the goto?
>{Actually, a break-from-labelled-statement would work too, but that's
>just another goto.}

	Not really.  The model for break-from-labelled-statement is a
stack of return points, a generalization of the procedure return point
stack.  With such a command you can only goto a point in the stack;
you are just going up several levels instead of one.  With a real goto
you can transfer to a point which is not in the stack.  [And, yes, I
know that you can simulate goto's with a breaks.  You can program recursion
in Fortran too.]

	As to your general point.  Without some sort of mechanism for
error handling escapes, one needs a goto to build it by hand.  C has a
goto, it doesn't have generalized escapes, and that's the way it is.
It would be awkward to simply delete the goto from C, to say nothing
of breaking a lot of existing code.  [Whether this code should have been
written that way is another matter.]

	I am still not convinced that the goto should be retained in a
successor language (e.g. D) -- it does seem to me that one could have
a more structured mechanism such as the break-from-labelled-statement
and dispense with goto's entirely.


>There's another reason for retaining the goto.  Look at the output of
>YACC some time.  I counted five labels in yyparse(), but may have
>missed some.  It isn't just people who write C, you know!  Why shouldn't
>people be allowed to write compilers which generate C?

	This may be a good argument, which I will pass onto those who
are better acquainted with the problems of writing programs which write
programs. 
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.