Contrary to popular reputation, there are a handful of use cases where "goto" makes the code simpler, cleaner, more readable, and (in rarer cases) faster. In these cases, you <i>should</i> use goto statements. A good programmer can recognize these cases and use goto appropriately. Goto is never necessary in a strict sense but occasionally it can eliminate some pretty ugly spaghetti code.<p>The use cases for goto I see are primarily complex/thorough error handling (e.g. unwinding some concurrency control mechanisms) and certain low-level state machine patterns. I would expect to see these kinds of use cases in the Linux kernel.
The original context of the "GOTO considered harmful" is lost on most of us, as at the time there were large swaths of developers that were trained <i>before</i> structured programming took off, so people were using global variables and GOTOs instead of procedures and functions. GOTO has its place, specially in C.<p>It is sinful to jump into a different function and pass around information as global state. GOTO as functionality is tangential in this matter.
Dogmatically following so called rules in a cargo cult programming style without any understanding of the rationale behind them is many orders of magnitude more bad.<p>This form of blind programming is terribly dangerous. It takes focus away from the task and placed on the process.<p>Engage with the problem, engage with the computer. Do not engage with autocratic decrees and programming equivalencies of heretic and kosher.<p>Goto does something specific. If you need that specific thing then that's why it's there. Ceremonial rituals be damned
At a glance, looks like most of 'em are used for error handling. Sort of a `try ... finally` for C. This is actually a fairly common pattern -- check out Python's source code for more examples.<p>The other way I've seen it used is to break out of multiple levels of nested loops, though that's far less common.<p>`goto` is bad when it's used in an unstructured way: e.g. A does some stuff, then `goto B`. Then B does some stuff, then `goto C`. C sets a flag, does more stuff, then `goto B`. B does something different this time around based upon the flag set by C. Jumping around in a completely uncontrolled way such that the code can't be comprehended is where goto is "bad".<p>goto isn't inherently bad, it's just easy to use it in bad ways (and once upon a time, people did so more so than they generally do today -- which iirc was Dijkstra's major beef with it)
Linus himself has publicly said he doesn't mind appropriate gotos. "I think goto's are fine, and they are often more readable than large amounts of indentation." Mind you this was 11 years ago, and it's weird to quote him as some sort of oracle. But it seems relevant.<p><a href="https://web.archive.org/web/20120331202351/http://kerneltrap.org/node/553/2131" rel="nofollow">https://web.archive.org/web/20120331202351/http://kerneltrap...</a>
They're usually used for an error clean-up section at the bottom.<p>Zed Shaw introduces some debug macros here which make use of a goto:<p><a href="http://c.learncodethehardway.org/book/ex20.html" rel="nofollow">http://c.learncodethehardway.org/book/ex20.html</a><p>From that point on in the book, pretty much every function written has an "error:" label at the bottom where stuff gets cleaned up and memory freed. You can see his example code for it there.<p>Pretty useful macros, really. Context for the "goto considered harmful" always seems lost on young coders these days, unaware of the kind of spaghetti code that overuse of goto had caused.
"Goto is bad" is something that professors tell first year computer science students because as computer scientists, the students will find novel ways of abusing them.<p>Using goto for error cleanup is pretty standard, easily readable, and understandable.<p>It avoids ugly braces and depth.<p>So, are gotos bad? It depends.
One of these days, "gotos: The Good Parts" will overshadow EWD's oft-abused essay, and the world will be spared highly nested, pointy-arrow C resource cleanup code.
Because they're not bad when you use them for actions which would go in a "finally" block in a language that supports exception handling.
I think what people are trying to say is that you shouldn't be taking too seriously all these advises about good and bad features in programming languages. Instead, try to understand the reasons behind such advises. All the bad things, that goto is blamed for, can be just as easily made with a bunch of methods in some object.
Even C# has the goto statement. <a href="http://weblogs.asp.net/stevewellens/why-goto-still-exists-in-c" rel="nofollow">http://weblogs.asp.net/stevewellens/why-goto-still-exists-in...</a>
without a goto, you have to rely on functions/return values/pointers, which implies a function call (sometimes billions of times), which can have performance and design implications.
Because it is written in C. "Goto statements are bad" meant: lets start using languages that offer higher level constructs to replace the current usage of goto. Things like "loops" and "functions" and "exceptions". C did not get the memo.
GOTO statements are not bad, they make your code run 10% faster while taking just 10 times as long to debug.<p>So if your code gets executed millions of times per second, like in some OS kernel, it may be wise to use GOTOs.<p>Otherwise, stay away.