2 ms·
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
by vunderba 1y ago
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.
- mock-possum 1y agoRight? f runs and immediately returns 0
- Wowfunhappy 1y agoThank you, I looked at this and thought I must be missing something really obvious.
- bramadityaw 1y agoI 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.
- gs17 1y agoI'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.
- bramadityaw 1y agoMy 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.