[TUHS] The UNIX Command Language (1976)
Larry McVoy
lm at mcvoy.com
Wed Dec 2 02:47:23 AEST 2020
On Tue, Dec 01, 2020 at 09:24:17AM -0700, Warner Losh wrote:
> On Tue, Dec 1, 2020 at 8:39 AM <arnold at skeeve.com> wrote:
>
> > It was recognized that goto was not necessary if one had proper control
> > structures in a language (if/else, while), and that code with no (or
> > minimal) gotos was easier to read and understand.
> >
>
> This is true for simple flow control. However, when you had to break out of
> multiple levels, or continue not the inner loop, but the middle loop, the
> use of extra booleans sure made the code less understandable than a 'goto'
> a label that stood in for that purpose... This was something that wasn't
> well understood by language designers, and even today C and C++ neither
> have good flow control beyond the basics. Even though both break and
> continue could take an optional count without breaking old code....
Probably need to move this to COFF... but.
Yeah, I've tons of examples of
int
somefunc()
{
char *a = 0;
int *b = 0;
flat *c = 0;
int ret = 0;
if (something) {
a = malloc(something);
} else {
ret = NO_SOMETHING;
goto error;
}
// same for b, c
error:
unless (ret) ret = GENERIC_ERROR;
if (a) free(a);
if (b) free(b);
if (c) free(c);
return (ret);
}
and you can handle a lot of simple cases that way. But sometimes the
unraveling is more difficult than a simple free so I might have a
goto unravel;
instead of the generic
goto out;
I love goto *if* you figure out a pattern for using it and stick to that.
For the people who don't like goto, what is your feeling on longjmp()?
More information about the TUHS
mailing list