OK, I know enough to know that sometimes I don't know everything, so if you guys are willing to beat this dead horse a little, the anti-goto cult is something I've been trying to understand for a long time.
I learned with BASIC (a couple decades ago), so I appreciate how it can get ugly in a hurry, and I appreciate the constructs of a language that help to avoid that sort of thing. I'm not in favor of throwing gotos in code willy-nilly, but I can't see the harm in the handful of patterns where I do tend to select it over alternatives. Clearly some disagree with this, and I realize it may just be a religious thing and there will never be agreement. I'm not 100% sure I'm at the point where I can't or won't change my mind, so if anyone else is up for a (friendly and productive!) argument, please take a chair... 
First, there were some good points over the weekend that I'd like to address:
vector0:
to end this war i started :
goto or not the compiler will anyway feed the assembler with jumps
Pretty much exactly my take on the matter as well. Now, true.. it's the point of higher-level languages to abstract the sequence of machine instructions to something that is easier, safer, and/or more efficient to maintain. So I guess it could be argued (playing devil's advocate here) that what the assembler does is irrelevant, since if you wanted to generate assembly language, there's a language specifically for that purpose. 
Docedison:
Speaking as a non skilled beginning programmer with a Basic language background and some time with '51 and PIC assembler...
Personally a Goto is a bone left over from the dark ages of C programming... When K&R were the new guys on the block This was I feel a sop to the languages that did support such nonsense
This is the logical counter-point to my assertion that "goto exists in C for a reason", and frankly it's a good point. It's easy to think of C as the gold standard to which many languages are compared, but also easy to forget that it, too, was new once upon a time. And so, goto could be considered baggage for the sake of compatibility before C became the reference with which to be compatible. I could learn to accept that.
pYro_65:
SirNickity, I might not have 30 years, but after 11 I can instantly see that exceptions are the logical answer to that solution. I know Arduino does not support exceptions, but wait there is more...
Neither does C. Sure, Arduino uses C++, but for the most part, I don't. That's a personal choice, partly because I haven't devoted the time to really learn C++, so at best I would be writing C with C++ extensions (and probably do a poor job at it.) Also, my tendency is to stay as "close to the metal" as I can.
C++ has some very worthy additions to C, but it also has abstractions that do things for you. I.e., overhead. Convenient, but overhead nonetheless. (Strings are a great example of this.) That's a philosophical thing -- not right or wrong, just my own taste. When convenience is truly more important than speed and code efficiency, I use languages like Perl. Tool == Job.
Some will argue that technology evolves, and C itself is a relic. I disagree. "Modern" languages have done a lot to prevent silly mistakes and common faults in code, and that's probably a good thing overall, as more people are writing code now than in the 70s, and not all of them are experts. Plus, machines are mostly bigger and faster while simultaneously more complex and trusted with more (in volume) sensitive information. Anything that prevents bugs then has obvious advantages. There's wisdom in that.
However, I still can't say I've ever used a program written in Java, C#, or various other "safe" languages that didn't feel at least a little bit heavier than a similar app in C. That could all be entirely circumstantial, and in particular, C++ is nowhere near the garbage-collecting, buffer-checking, hand-holding monstrosity that typical VM-based languages are, but still...
Learning to do things without all the safety nets is, if nothing else, a good exercise in awareness for when such tools are justified. For example, when the possibility of mistakes is more of a threat than a hit to performance. For me, and most of the things I do, I prefer the efficiency of plain old C. I acknowledge that I am guilty of willful ignorance by not taking more time to learn C++ and having that tool at my disposal where it is appropriate.
I digress though...
pYro_65:
Its just a quick and dirty hack that can be exceptionally bad when used incorrect, of course if used well it may save a cycle or two, but that's about it. In fact as the goto label is executed before return, regardless of goto, the loops can be controlled with break and continue.
CAN be exceptionally bad, I agree. How often does anyone really write spaghetti code though? Can it still be spaghetti with one noodle? Break and continue are gotos with a pre-defined label after all. (Although, certainly this rationale gets dangerously close to that "what the compiler does" argument above.)
I can't hold the potential for misuse against a feature that has equal potential for genuine utility. We all have potential to write poor code, and we all realize that potential on a regular basis -- with and without goto. 
Let's deal with issues with structure and syntax, and not go all Minority Report on one poor keyword.
pYro_65:
Anywhere you use goto is a clear indicator that the higher level design is flawed, one single function may not be to blame, it could be an amalgamation your entire project.
You might just as well argue that anywhere you see a blanket bias against a language construct is a clear indication of blindly following principal, not considering what's really best for the situation at hand. People CAN use misuse goto. When used an alternative to break/continue that goes to a user-defined label, I feel like we're comparing apples and oranges, and just holding on to long-standing prejudices borne from less sophisticated languages and their inherent flaws.
pYro_65:
Consider this:if (rval != ERR_OK) goto cleanup;
//while loop is next.
This would only be equal to, never faster than simply putting the entire while loop inside the if: > if (rval <mark>==</mark> ERR_OK){ > //While loop here > } Obviously this programmer simply likes using goto, and has not put substantial thought into a correct and logical program flow.
"This programmer" was me. I don't "like" using goto any more than I like using "if". It's a tool, one of many, and sometimes one of a few that are functionally equivalent. I choose the one that seems to make the most sense at the time. Sometimes I later go back and revise the code and choose another. (This is greatly aided by reading the code after a weekend or more of being away from it, and judging if the flow still seems logical and obvious, or whether it seems forced. Sometimes the initial choice was poor. It happens.)
Now, yes, you could do this:
if (rval == ERR_OK) {
while (...) {
....
}
} // if
...but IMHO, that is a truly horrible way to write code. I hate seeing page(s)-long braces of an if statement when a simple logical inversion and a quick exit could have reduced the indent of several dozen lines.... 
You're just asking to lose track of which '{' lines up with which '}' in that case. Leaning on an editor to highlight this for you is at best a band-aid to what is IMO a greater offense against clarity than using goto. If I misunderstood your intent and am barking up the wrong tree, please correct me.