1 Dec
2020
1 Dec
'20
10:47 p.m.
On Tue, Dec 01, 2020 at 09:24:17AM -0700, Warner Losh wrote:
On Tue, Dec 1, 2020 at 8:39 AM
<arnold(a)skeeve.com> wrote:
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()?
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....