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.
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.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.
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.
goto out makes code so much cleaner and people should stop pretending it doesn't.
“Goto Rendered Harmless”