Path: ...!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: goto considered helpful
Date: Fri, 13 Dec 2024 14:50:26 +0100
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <vjhe33$3ema7$1@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me> <87ldwx10gv.fsf@bsb.me.uk>
 <vimtt4$27vv$1@dont-email.me> <86ser1kgp5.fsf@linuxsc.com>
 <vit69t$1qfgg$1@dont-email.me> <87ldwtzlc0.fsf@nosuchdomain.example.com>
 <vitjgg$1tukq$2@dont-email.me> <vj1bss$325uo$1@dont-email.me>
 <vj1h4i$335q1$2@dont-email.me> <vj1mhi$34p7h$1@dont-email.me>
 <vj1prj$35je4$1@dont-email.me> <vj7dup$he7i$1@dont-email.me>
 <vjasuj$17uod$1@dont-email.me> <vjc87h$1apid$1@paganini.bofh.team>
 <vjcbe1$1jns0$1@dont-email.me> <87wmg5x4b1.fsf@nosuchdomain.example.com>
 <vjd96b$1pbed$1@dont-email.me> <87jzc5wx3s.fsf@nosuchdomain.example.com>
 <vjdde8$1q2to$2@dont-email.me> <87frmtwuzq.fsf@nosuchdomain.example.com>
 <20241212144454.00003b83@yahoo.com> <87wmg4vaeb.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 13 Dec 2024 14:50:28 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9ac4af56cbfb1c4952f643dba36c3548";
	logging-data="3627335"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+uVb8c7rCPCBwl2amZZ5uS"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:VSM7hZeP+yoC2BMkveS5eNlUsZ4=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <87wmg4vaeb.fsf@nosuchdomain.example.com>
Bytes: 4312

On 12.12.2024 22:50, Keith Thompson wrote:
> 
> Backward gotos tend to be dangerous.  Forward gotos are less so.

I think I agree.

> 
> Dijkstras original "Go To Statement Considered Harmful" letter was
> written in 1968, at a time when many languages didn't necessarily
> have the structured control constructs we've come to expect since
> then.  Using goto to implement a loop is almost always a bad idea,
> but it's something that a modern C programmer probably wouldn't
> even consider doing.

Also in languages with control constructs it could be observed that
there was a tendency to write "spaghetti-code" with 'goto'. And yes,
that observation was certainly the reason for Dijkstra's paper.

> 
> I agree that gotos have valid uses.

I'm unable to provide references, but from faint memories I recall
that exiting deeply nested loops was academically mentioned to be
such a "valid" use of 'goto'. - And, frankly, I've rarely seen (or
felt the need) for [sensible] other uses of 'goto'. One other use
was to implement an (explicitly programmed, not table-driven) FSA
(but personally I'm using other methods even for that application
case).

> 
> Here's an answer I wrote on Stack Exchange some years ago to the
> question "Is using goto ever worthwhile?" :
> [...]
> 
> I would support adding named loops and labeled exit/continue to
> a future version of C.  I've used languages that have similar
> features, and have found them very useful.  Given that C doesn't
> have multi-level break, I tend to agree that a goto statement is a
> reasonable way to simulate it, often better than the alternatives.

Yes, that might be the case.

I'm not so sure about the idea of adding yet more jump-types. I
consider 'break' as a camouflage to not make that "evil goto" too
obvious and to restrict its "wildness" to a safer program context
(that also makes things like stack-unrolling etc. superfluous).
Give how rarely (IME) they seem to be used one 'goto' seems to be
enough - but 'break' and 'continue' are useful in specific types
of program logic, though 'break' with numbers as arguments (that
I used once or twice in Unix shell) I'd not consider to be a good
idea; labels would certainly be better.

> [...]
> 
> Here's an example of a small C program that completely avoids the
> use of goto statements.  I reserve the right to ridicule anyone who
> takes this program seriously.

Thanks for the warning! :-)

> 
> [ source code with lots of setjmp/longjmp ]

Janis