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

On 24.06.2024 01:36, Ben Bacarisse wrote:

[...]

 
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.

This is the same impetus I have.

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.

I recall from past decades that I've seen only one specific code
pattern where I'd say that 'goto' would not make a program worse
(or even make it simpler); it is a (more or less) deeply nested
imperative code construct of loops where we want to leave from
the innermost loop. Propagating the exit condition through all
the nested loops "to the surface" complicates the code here. The
introduction of additional state or duplication of code is what
the literature (dating back to "goto considered harmful" times)
gives as (sole) rationale for its use.

It still has an inherent "bad smell" since you can circumvent a
lot code (even leaving stack contexts). Some languages have thus
introduced yet more restricted forms; e.g. the 'break N' in the
Unix standard shell language, allowing one to leave N levels of
nested (for/while/until) loops.

Janis