There, now would you mind going back and reading what I actually wrote?
edit: Hmm, so I skimmed a few replies above and see just the piggy-backing on Nick's reply and "using that reply to read my post", so let me make this much bigger for your reading ability:I don't mean using goto in place of a loop is somehow going to magically save a bunch of code. Far the hell from it.
... it's simply a case of using the right tool for the job. The goto statement has its uses, in possibly 0.01% of cases.
Probably the most famous criticism of GOTO is a 1968 letter by Edsger Dijkstra called Go To Statement Considered Harmful.
Some programmers, such as Linux Kernel designer and coder Linus Torvalds or software engineer and book author Steve McConnell also object to Dijkstra's point of view, stating that GOTOs can be a useful language feature, improving program speed, size and code clearness, but only when used in a sensible way by a comparably sensible programmer.
To be fair, I believe he was referring to optimizations which are possible because of default flow-throughs and jumps, whereby its possible to avoid the expense of some comparisons. And/or a combination of jump tables. Obviously practical gains there would be CPU/architecture dependent based on the costs of jumps vs jump comparisons, branch prediction, and cache/pipeline availability. And in complex cases where multiple comparisons are required, its frequently possible to avoid multiple comparisons whereby progressive defaults can be assumed, saving some here and there. Typically a case a real rat's nest of logic is required and a goto can help alleviate, but even then, actual savings may not be there.
start: LATCH_ON(); LATCH_OFF(); LATCH_ON(); LATCH_OFF(); goto start;
The goto didn't save time. It was changing the code to omit the repeated function calls that saved time. But you can do that without using goto.
And the result: goto is faster than using a function call, end of story.
cut my teeth on an IBM360 and a DEC PDP11/45; one had a stack, the other didn't.