Even though it’s not the main focus of the article, the sample code's odd structure is a bit distracting.
int f()
{
foo:
return 0;
goto bar;
}
int g()
{
bar:
return 1;
goto foo;
}
int main()
{
return f();
}
It's treating both "foo" and "bar" like the equivalents of encapsulated subroutines, but the goto statements will NEVER be executed unless there's a C variant or compiler switch I'm unfamiliar with.
My point is exactly that. C is a structured, procedural programming language that will only consider procedurally scoped labels. You can't execute it because it is not valid C that a standard compiler would accept, and we should be thankful because of that.
I admit that the example is contrived, and the control flow can be followed quite clearly because of the example's size.
However, imagine that f and g is placed in different source files in a large project. That's what Dijkstra detests about arbitrary labels, in that a program's control flow is only obvious to the guy who first wrote it.
Goto can be used safely but that’s really just arguing that “harmful” should instead be something like “risky”. If you have robust flow analysis and testing, you can certainly find advantages but it’s kind of like seeing someone doing mountain bike tricks on YouTube and then asking whether you should try that on your commute to work. The Linux kernel developers are in an unusual position of being both extremely performance sensitive and supported with review and testing resources compared to almost anyone else.
As far as I can tell, gotos are essential for maintainable c-code.
In particular, having an end label in a function that handles freeing intermediate variables that may or may not have been allocated is vital for functions with multiple (logical) return points. As are fail labels where appropriate.
Appropriate use of goto is literally written into the internal C style guide where I work. This is not about performance; it is entirely about avoiding memory bugs.
Maybe this will go away when defer becomes a thing. But seeing as people still target C99, that might take a while.
Even though it’s not the main focus of the article, the sample code's odd structure is a bit distracting.
It's treating both "foo" and "bar" like the equivalents of encapsulated subroutines, but the goto statements will NEVER be executed unless there's a C variant or compiler switch I'm unfamiliar with.My point is exactly that. C is a structured, procedural programming language that will only consider procedurally scoped labels. You can't execute it because it is not valid C that a standard compiler would accept, and we should be thankful because of that.
I'm not even sure if the gotos not doing anything is the point or not. It definitely makes it less "harmful", at the cost of also not being useful.
Right? f runs and immediately returns 0
Thank you, I looked at this and thought I must be missing something really obvious.
I admit that the example is contrived, and the control flow can be followed quite clearly because of the example's size. However, imagine that f and g is placed in different source files in a large project. That's what Dijkstra detests about arbitrary labels, in that a program's control flow is only obvious to the guy who first wrote it.
Goto can be used safely but that’s really just arguing that “harmful” should instead be something like “risky”. If you have robust flow analysis and testing, you can certainly find advantages but it’s kind of like seeing someone doing mountain bike tricks on YouTube and then asking whether you should try that on your commute to work. The Linux kernel developers are in an unusual position of being both extremely performance sensitive and supported with review and testing resources compared to almost anyone else.
As far as I can tell, gotos are essential for maintainable c-code.
In particular, having an end label in a function that handles freeing intermediate variables that may or may not have been allocated is vital for functions with multiple (logical) return points. As are fail labels where appropriate.
Appropriate use of goto is literally written into the internal C style guide where I work. This is not about performance; it is entirely about avoiding memory bugs.
Maybe this will go away when defer becomes a thing. But seeing as people still target C99, that might take a while.
As long as memory management and stacks are in order, they are ok to use.
Java still allows you to continue/break to labels
goto out makes code so much cleaner and people should stop pretending it doesn't.
“Goto Rendered Harmless”
I consider this the official alternative title :)