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.
EDIT: Upon closer inspection it seems like even if 'gotos' make everything nastier the extra added performance is worth it.
It is sinful to jump into a different function and pass around information as global state. GOTO as functionality is tangential in this matter.
I've heard of that. It's called "exceptions", right?
I find it kind of amusing when people are afraid of "goto" but not "throw", "break" or "return".
So sinful you can't in C
https://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Labels-as-Values....
This form of blind programming is terribly dangerous. It takes focus away from the task and placed on the process.
Engage with the problem, engage with the computer. Do not engage with autocratic decrees and programming equivalencies of heretic and kosher.
Goto does something specific. If you need that specific thing then that's why it's there. Ceremonial rituals be damned
The other way I've seen it used is to break out of multiple levels of nested loops, though that's far less common.
`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".
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)
https://web.archive.org/web/20120331202351/http://kerneltrap...
Zed Shaw introduces some debug macros here which make use of a goto:
http://c.learncodethehardway.org/book/ex20.html
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.
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.
Also, never pass up the opportunity to troll a god-fearing "goto puritan" :-)
Using goto for error cleanup is pretty standard, easily readable, and understandable.
It avoids ugly braces and depth.
So, are gotos bad? It depends.
Writing something in C does not automatically imply having to use goto.
> "Goto statements are bad"
Goto statements are not bad.
> Things like "loops" and "functions" and "exceptions". C did not get the memo.
C has loops and functions. Bro do you even K&R?
It might be a good idea to know what you're going to be talking about before opening your mouth.
I didn't say it did. But any large enough C project will obviously use them.
>Goto statements are not bad.
Do you know what quotation marks are?
>C has loops and functions
It does not have exceptions. Which is what all the goto uses in question are being used for.
>It might be a good idea to know what you're going to be talking about before opening your mouth.
How ironic.
Which leaves...
> But you're right that modern use of goto is typically used in error handling to replace specific use cases of exceptions in a primitive way
Exactly. I pointed out the context of "goto considered harmful". Obviously the one that applies to C is the one that is the reason for all the gotos in C code.
So if your code gets executed millions of times per second, like in some OS kernel, it may be wise to use GOTOs.
Otherwise, stay away.
Sure, you can store them wherever, and do something like " goto *g_greenthreads[ threadno ].lastpos ", but you would call that within the function defining the label, not outside it.
From your own link: > You may not use this mechanism to jump to code in a different function. If you do that, totally unpredictable things will happen. The best way to avoid this is to store the label address only in automatic variables and never pass it as an argument.
An exception is still essentially a goto that crosses stack frames. There is a whole class of common bugs, you will see a lot of talk of them in the C and C++ communities, where an early return or a throw at an unexpected time leads to resources not being cleaned up. A lot of good coding styles say avoid this stuff, it's dangerous, and they are not without cause. Whereas a goto cleanup block is often a lot more explicit and therefore can lead to more reliable code than a scheme that encourages not sweating details and not expecting failure at every step.