Re: [TUHS] The UNIX Command Language (1976)

[Larry McVoy <lm@mcvoy.com>]

On Tue, Dec 01, 2020 at 09:24:17AM -0700, Warner Losh wrote:
> On Tue, Dec 1, 2020 at 8:39 AM <arnold@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()?