Path: ...!feeds.phibee-telecom.net!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: Fixing a sample from K&R book using cake static analyser
Date: Mon, 24 Jun 2024 04:38:54 +0200
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <v5am80$o3os$1@dont-email.me>
References: <v53sl1$35qt7$1@dont-email.me> <v558hv$3dskb$1@dont-email.me>
 <20240623022343.ec355c69a3d9eb03ad4a50f2@gmail.moc>
 <878qywq7ou.fsf@bsb.me.uk>
 <20240624013337.36fdb40f0766c6e1c8ce67c7@gmail.moc>
 <87tthjnsdt.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 24 Jun 2024 04:38:56 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8b06e05337e091ed4f227526767ebb5e";
	logging-data="790300"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/By81YtF63eO7mjylx186Z"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:mb8KDCDIaQFlz/lO+D2dii3/ppk=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <87tthjnsdt.fsf@bsb.me.uk>
Bytes: 2867

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