Re: Fixing a sample from K&R book using cake static analyser

Anton Shepelev <anton.txt@gmail.moc> writes:

Ben Bacarisse to Anton Shelelev:
>

Why are you so afraid of `goto' that you must emulate it
with `while' and `break'?

>
Why are you so fond of them that you add three extra state
variables that have to be (mentally and/or mathematically
tracked) just understand this supposedly simply function?

>
Because my attempts to fix the function without the extra
variables proved even worse.

OK, but two labels and three extra state variables makes it much more
complex to think about.  I don't think the simple "if this then that"
approach is at all problematic in this case.  I can't see why adding
even one goto helps when the structured approach is so simple.

(I've tried to show this with code in another reply.)

This, to me, is a textbook case of why goto is harmful.  I
have spend considerable time jumping up and down checking
the state of all the variables and I am still not sure I
follow what this supposedly simple function is doing.

>
I have tried to keep the structure simple: all the goto's
jump down, both the labels define isolated blocks, guared by
returns, to prevent fall-though.

Trying to make gotos less bad than they can be is not usually an overall
positive.  Whenever I see a "good" use of goto, I try to see if there's
a better way with no use of goto.  So far (with the exception of an
example of tightly bound co-routines being simulated in a single C
function) I have not yet seen one that can't.  There are sometimes
run-time considerations (giant state machines, for example) but even
there the structured code is probably clearer.  The use of gotos in
those cases is not to improve the logic of the code but to placate the
code generator.

--
Ben.