SirNickity:
OK, then humor me. What's the 30-years' experience alternative to this typical situation?This is an anonymous and contrived example -- not a direct copy of a real driver, but close enough to a LOT of loops-within-loops I've had to write recently. (E.g., file read loop with a buffer processing loop within.) The cleanup portion is fairly benign here. In real code, it can easily be half a dozen statements long. You could put those inline anywhere there's a goto above, or use a flag variable and bail out if it's set, or any of a dozen other techniques... But I fail to see what's so gosh-darn diabolical about the obvious and tidy goto approach? It works, the purpose is clear, the code path is trivial to follow, it keeps you from having to write redundant cleanup code (and these loops are fairly short, with few exit points -- there could be a lot more!), and it prevents errors if you have to free memory or restore flags or whatever else you might forget to do otherwise.
A LOT of very real, very thoroughly vetted, production-level code uses this pattern. I cannot imagine, if there were truly something harmful about it, that you would see this in so many ubiquitous codebases -- like the Linux kernel, OpenSSL, Firefox ....
Nonetheless, I am willing to hear the counter-argument if someone feels compelled to plead their case. I don't expect it'll make the wholesale ban any less nonsensical to me, but who knows?
It would be relatively easy to restructure the code to make the loop conditional on one or more error values. My experience is that when people use goto statements, it makes the code fragile. Suppose the next person to work on it needs to support a slightly different error handling for a different type of error code so adds another goto label. The first goto may seem like a great idea but it is first step towards a rewrite.
We had this debate at work many, many times. The argument in favor of goto statements was basically "yes, it is bad but it's quick and easy and I'm a good enough programmer to handle it". My response was that some of our code was 20 years old and had many, many programmers changing it over the years. It was complex code the day it was written (drug design software) and the last thing it needed was anything that made it more fragile or complex.