An amusing piece of code

kenny at uiucdcsb.CS.UIUC.EDU kenny at uiucdcsb.CS.UIUC.EDU
Thu Apr 17 04:02:00 AEST 1986


/* Written  4:26 pm  Apr 12, 1986 by stevesu at copper.UUCP in uiucdcsb:net.lang.c */
Most people agree that goto's are pretty acceptable for handling
error conditions.  For instance:

	if(stbuf.st_uid != getuid())
		{
nope:		printf("I don't think you want to delete this file.\n");
		return;
		}

	if(strcmp(name, "vmunix") == 0)
		goto nope;

	unlink(name);

	return;

                                         Steve Summit
                                         tektronix!copper!stevesu
/* End of text from uiucdcsb:net.lang.c */
You've chosen a pretty bad example.  It's more sensible to code what you're
writing as:

	if (stbuf.st_uid != getuid ()
	 || strcmp (name, "vmunix") == 0) {
		printf ("I don't think you want to delete this file.\n");
		}
	else {
		unlink (name);
		}

The real use of goto's as error exits is as a panic exit from a set of 
deeply nested control structures; this is generally a goto *out* of a block
and not *into* one:

	while (something)
		while (something else)
			if (something terrible happens) goto quit;
			....

	return;

quit:
	(handle the error here)

with as many goto's as are necessary to handle all the error conditions.
In many cases this panic exit actually has to cross function boundaries;
a reason that I insist (over some of my more academically minded colleagues'
loud objections) that setjmp/longjmp pairs are a necessary evil.

In short, the use of goto as an error exit is a red herring when discussing
whether goto into blocks is permissible.  My $.02 says that it isn't necessary,
ever, and it really messes up any serious attempt to optimize, so why not trash
it?

Kevin Kenny
University of Illinois at Urbana-Champaign
UUCP: {ihnp4,pur-ee,convex}!uiucdcs!kenny 
CSNET:	kenny at UIUC.CSNET
ARPA:	kenny at B.CS.UIUC.EDU	(kenny at UIUC.ARPA)

"Yes, understanding today's complex world is a bit like having bees live in
your head, but there they are."



More information about the Comp.lang.c mailing list