gotos

[Richard Harter]

	I suppose there is some justification for the recurring issue
of gotos -- it usually raises some interesting issues of coding technique.
It's not a profound topic, but it's fun for all concerned.  It seems to me
that the profit, if any, in these exercises is to analyze these little
difficulties and spot where the problem is and what a good resolution is.

	In the case in hand we have a very common task -- there are a
series of actions.  After each action we check to see if a certain thing
has happened -- if it has we cease stepping through the actions and go
on to the next stage.  The proposed techniques include

a)	Use goto's at each checkpoint which branch to a common label

b)	Fake it with a block and break statements

c)	Use nested if's

d)	Use a signal handler.

The signal handler approach is pretty, but it isn't general, and doesn't
really work right in this case.  The nested if's approach is, in my view,
worse than using goto's -- it buries the essential structure of the task
rather than explicates it.  Block and break is fine as long as it is con-
venient to put all the tests at the first level.  So far, however, nobody
has really made a good case for not using goto's for this kind of task,
as far as I can see, other than it is naughty to use goto's.  Here are
some more alternatives:

e)	Put the sequence of actions in a function and get out with return
	statements.  Much the same as block and break, except that you
	can do deep level escapes.

f)	Put the test condition in a while statement and step through the
	actions [somehow].  Unfortunately, I don't see a nice way to do
	this in C.  The thought that first occurs to one is something like

for (step=0,done=0;!done;step++) {
  switch(step) {
    case 0:  action_0;
             break;
    case 1:  action_1;
             break;
    ......
    default: done = 1;
             break;
    }
  if (!done && test_condition) done=1;
  }

which is all very well in its way (there is now only one expression of
the test condition) but does look remarkably clumsy and is a maintenance
problem (what happens when you want to insert a new action?).  Perhaps
someone else has a neater way to do it.

In assembly language this type of situation is a natural for threaded code.
The labels for the action sequences go on a stack.  After each action you
branch to the test code, which in turn pops the next action label.  All
very straightforward, but I don't really see a nice way to implement threaded
code in C without using function arrays.
-- 

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