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.
