The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Larry McVoy <lm@mcvoy.com>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: tuhs@tuhs.org
Subject: [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary
Date: Fri, 10 Mar 2023 07:46:02 -0800	[thread overview]
Message-ID: <20230310154602.GX9225@mcvoy.com> (raw)
In-Reply-To: <20230310153702.AFF3418C080@mercury.lcs.mit.edu>

I've used gotos for decades but in a "structured" way.  My functions 
have a pattern:

	<allocation section>
	<work section>
	<deallocation section>

and there are a series of labels in the deallocation section.  Then while
you are wandering through the allocation section, you can jump to the 
right spot in the deallocation section.

And yes, this is a simplification because I initialize all my pointers to
NULL so the deallocation is all 

	if (p) free(p);

but the idea is the same.  You wind up some state and wind down some state
and the gotos are used to jump to the right place to unwind.

On Fri, Mar 10, 2023 at 10:37:02AM -0500, Noel Chiappa wrote:
>     > From: "Ronald Natalie"
> 
>     > Multilevel breaks are as bad as goto with regard to structure violation.
> 
> In a way, you are right. There isn't really much difference between:
> 
> 	for (mumble) {
> 		for (foobar) {
> 			do some stuff
> 			break-2;
> 			}
> 		}
> 
> and:
> 
> 	for (mumble) {
> 		for (foobar) {
> 			do some stuff
> 			goto all_loops_done;
> 			}
> 		}
> 	all_loops_done:
> 
> 
> The former is basically just 'syntactic sugar' for the latter.
> 
> I think the point is that goto's aren't necessarily _always_ bad, in and of
> themselves; it's _how_, _where_ and _why_ one uses them. If one uses goto's
> in a _structured_ way (oxymoronic as that sounds), to get around things that
> are lacking in the language's flow-control, they're probably fine.
> 
> Then, of course, one gets into the usual shrubbery of 'but suppose someone
> uses them in a way that's _not_ structured?' There's no fixing stupid, is my
> response. Nested 'if/then/else' can be used to write comletely
> incomprehensible code (I have an amusing story about that) - but that's not
> an argument against nested 'if/then/else'.
> 
> As I've said before, the best sculpting tools in the world won't make a great
> sculptor out of a ham-handed bozo.
> 
> 	Noel

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

  reply	other threads:[~2023-03-10 15:46 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10 15:37 Noel Chiappa
2023-03-10 15:46 ` Larry McVoy [this message]
2023-03-10 16:04 ` Dan Cross
2023-03-10 18:55 ` Ron Natalie
2023-03-10 19:04   ` Dan Cross
2023-03-10 19:35     ` segaloco via TUHS
  -- strict thread matches above, loose matches on Subject: below --
2023-03-10 11:51 Noel Chiappa
2023-03-10 14:16 ` Ronald Natalie
2023-03-10 14:39   ` John Cowan
2023-03-10 16:30   ` Phil Budne
2023-03-10 17:50     ` Steffen Nurpmeso
2023-03-10 17:57       ` Paul Winalski
2023-03-10 18:12         ` Lawrence Stewart
2023-03-10 17:28   ` Clem Cole
2023-03-10 17:54     ` Paul Winalski
2023-03-10 11:37 Noel Chiappa
2023-03-10 15:54 ` Dan Cross
2023-03-12  7:39   ` Anthony Martin
2023-03-12 11:40     ` Dan Cross
2023-03-12 16:40       ` Paul Winalski
2023-03-13  3:25       ` John Cowan
2023-03-13 10:40         ` Alejandro Colomar (man-pages)
2023-03-13 12:19           ` Dan Cross
2023-03-09 23:01 [TUHS] " Steffen Nurpmeso
2023-03-09 23:18 ` [TUHS] " segaloco via TUHS
2023-03-09 23:21   ` Warner Losh
2023-03-09 23:31     ` Luther Johnson
2023-03-09 23:44       ` josh
2023-03-09 23:54       ` Warner Losh
2023-03-10  0:54         ` segaloco via TUHS
2023-03-10  1:08           ` Warner Losh
2023-03-10 10:08             ` Ralph Corderoy
2023-03-10 11:37               ` arnold
2023-03-10 11:56                 ` Ralph Corderoy
2023-03-10 11:59                   ` arnold
2023-03-10 12:11                     ` Ralph Corderoy
2023-03-10  6:15     ` Dave Horsfall
2023-03-10 16:55       ` Steffen Nurpmeso
2023-03-10 17:02         ` Bakul Shah
2023-03-12 20:47         ` Dave Horsfall
2023-03-12 21:50           ` Warner Losh
2023-03-12 22:27             ` Steffen Nurpmeso
2023-03-10  1:31   ` Rich Morin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230310154602.GX9225@mcvoy.com \
    --to=lm@mcvoy.com \
    --cc=jnc@mercury.lcs.mit.edu \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).