Goto Considered Harmless
bramadityaw.github.io
Goto Considered Harmless
1–10 of 13 posts
Re: Goto Considered Harmless
#2“Goto Rendered Harmless”
Re: Goto Considered Harmless
#3Even 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();
}
Re: Goto Considered Harmless
#4Goto 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.
Re: Goto Considered Harmless
#5goto out makes code so much cleaner and people should stop pretending it doesn't.
Re: Goto Considered Harmless
#6Even 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.
Right? f runs and immediately returns 0
Re: Goto Considered Harmless
#7Even 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.
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.
Re: Goto Considered Harmless
#8Even 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.
Right? f runs and immediately returns 0
Thank you, I looked at this and thought I must be missing something really obvious.
Re: Goto Considered Harmless
#9Goto 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 perfo…
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.
Re: Goto Considered Harmless
#10As long as memory management and stacks are in order, they are ok to use.
Java still allows you to continue/break to labels