Right. He was criticizing the version where one subroutine might jump into the middle of another subroutine. That sort of thing can make safely modifying the s

Right. He was criticizing the version where one subroutine might jump into the middle of another subroutine. That sort of thing can make safely modifying the second subroutine require knowing if any of its labels are used elsewhere in the program. It is basically impossible to reason locally when developing like that, unless you first verify that the only uses are local. (Or have applied strict coding standards such that only labels specifically identified can be used as non-local goto targets, etc.) That sort of thing was extremely normal in say early assembly programming where your code size was so restricted, you needed to reuse code whenever possible. And many early languages brought that sort of capability along with it. I'd expect Dijkstra's feeling on C's goto would probably be like: Probably a good idea to avoid it when the other control structures work well, but barring silliness like trying to code a large program in a single function, using C's goto for cases not well handled by the other control structures is fine, since it is constrained to local use only.