Am I going to programmer hell now? 
The code goes something like
IF a_common_event // we expect this to happen a lot
do_audit := TRUE
GOTO write_audit
END IF
IF rare_event1
OR rare_event2
OR rare_event3
OR . . . an enormously long list of rare_events
do_audit := TRUE
END IF
<<write_audit>>
IF do_audit THEN
do_audit_stuff()
END IF
I know there are loads of coders out there how often do you resort to a naughty goto?
Just make *write_audit * a subroutine and invoke it on true.
I’ll pretend we never had this conversation. 
The code you show can be accomplised thusly:
do_audit_stuff()
As written, you set do_audit to true under all circumstances and then check to see if it’s true.
The separate IF gains you nothing. Given a whole bunch of conditions linked by ORs, the whole thing becomes true as soon as any one of 'em is, and the dumb box ought to stop evaluating conditions at that point and cut to the chase. You put the commonest condition first.
I’ve never understood the irrational hatred of the humble GOTO. There are times when it is perfectly appropriate and the best solution.
GOTO’s don’t make spaghetti code; programmers make spaghetti code.
GOTO your room! 
“I command you, unclean spirit, whoever you are, along with all your minions now attacking this servant of God, by the mysteries of the incarnation, passion, resurrection and ascension of our Lord Jesus Christ, by the descent of the Holy Spirit, by the coming of our Lord for judgment, that you tell me by some sign your name, and the day and hour of your departure. I command you, moreover, to obey me to the letter, I who am a minister of God despite my unworthiness; nor shall you be emboldened to harm in any way this creature of God, or the bystanders, or any of their possessions.”
True. The real code isn’t actually structured as a chain of ORs, it was just easier to represent it like that.
I made spaghetti last night, near enough?
I’m pretty sure that the last time I used a goto was when I was playing around with BASIC on a TRS-80 back in the early 80s. (And I was 12 or 13 at the time).
I’ve never actually used one in C++, or anything more recent.
Yes, but the situations where GOTOs are warranted are relatively uncommon. Most novice programmers abuse GOTOs, rather than use them judiciously.
The legendary Donald Knuth, on the other hand, was known for using GOTOs well in his classic The Art of Computer Programming series.
As for the OP, the two IF statements could have been collapsed into a single one with no loss of performance, if the compiler uses short-circuited logic. If not, a simple “IF… THEN… ELSE” construct would have worked as well.
What is it that your code is actually trying to accomplish? Is it ever the case that you don’t want to do_audit_stuff? If so, then . . .
If (list of conditions under which audit stuff should be done)
do audit stuff
End if
Am I missing something? Please explain.
This is the critical point. Are there good uses of the GOTO? Maybe. But when I have this discussion with programming students, who always want to argue the case, none of their presented arguments are of the “good uses” variety (e.g. see example presented in OP). Most students, to be honest, seem to just want to use gotos because they’ve been told they shouldn’t. The good/bad use doesn’t really factor in except as an excuse.
So it’s easier to forbid them altogether to students. I can’t think of a case in which removing a goto results in significantly harder to understand code, so I’m not penalizing them adversely. If a programmer later in life comes across a case where it’s better, they at least have the knowledge of the other options, and can make an informed decision.
A number of software engineering books seem to consider the “goto end on error” metaphor–when there are several jumps to the label in the routine from rare conditions, not like the OP-- to be an (the sole?) acceptable use of a GOTO.
Even that support seems to be eroding, though, in languages which support structured exception handling (Java, anything.NET, C++, several others).
A “try block” around the code with the potential errors, with the GOTO’s replaced by “throws”, gives you code of roughly the same size, plus the ability to handle the exception at another level entirely, plus the ability to write consistent exception handling throughout the application (you could call a function to report the caught error, for example), plus a method whose actual NAME implies you’re handling exceptions, plus debugging support on the throw and catch, plus automatic stack unwinds (and object destructors called in C++)…
Of course, not all languages have exception handling. In that case, the GOTO may still be the clean solution. That having been said, it’s been decades since I used one in any language - the alternatives are just never all that bad.
I have often thought that gotos have a bum reputation. Like any other logic structure they can make for unreadable/unsupportable code, but they can be used well. Understand though that most of the places that they can be used, another logic structure could be equally well employed. I don’t use them, but I don’t feel they are as horrible as people say.
laina_f The (real) code acomplishes fine thanks 
The point is there are many dozens of changes that could happen. Only one or two that we really expect to see, the rest will rarely (possibly never) happen. I didn’t want to lump the common events in the same OR test as something that’s as likely as a meteorite strike, they may logically fit together but not (excuse the word) conceptually.
IF ClangerDrinksTea
OR ClangerWinsLottery
OR ClangerIsHitByMeteorite*****
THEN. . .
See what I mean?
*****Back on the home planet of course this is not so unlikely.
Well I like gotos…
sqrtTable[0x400]; /* example of building lookup table */
for (L = 0; L | 0x400; L++) {
sqrtTable[L] = (L * L);
}
__inline unsigned int fsqrt(unsigned int value) { /* square root function which works on a 16/16 fixed point integer */
unsigned int returnValue;
_asm {
mov eax, 0; //low value in eax
mov edx, 0x3ff; //high value in edx
mov edi, 0x1ff; //curr test in edi
lea esi, sqrtTable; //lookup table in esi
mov ecx, value; //number we are looking for
shr ecx, 12; //lose all but 4 decimal bits (16.4 fixed point)
LOOP_TOP:
mov ebx, [esi + edi * 4]; //grab the test number -- in ebx
cmp ebx, ecx;
je LOOP_END; //found it!
jl LESS; //below us
mov edx, edi; //get average of high and curr values and set as new curr
add edi, eax;
shr edi, 1;
jmp COMPARE_END; //prepare for next loop
LESS:
mov eax, edi; //get average of low and curr values and set as new curr
add edi, edx;
shr edi, 1;
COMPARE_END:
mov ebx, eax; //verify that our high and low points haven't converged
cmp ebx, edx;
je CONVERGED; //done!
inc ebx; //Or, if they are one off from each other
cmp ebx, edx;
je CONVERGED; //done!
jmp LOOP_TOP; //try again...
CONVERGED: //use low as the value we want
mov edi, eax;
LOOP_END:
shl edi, 14; //result only has 2 decimal bits (8.2)
mov returnValue, edi; //and pass it back to C
}
return returnValue;
}
When I was in high school, I was going to buy a GOTO, but ended up with the 455 Trans Am instead.
That’s what you meant, right?
Why don’t you GOSUB yourself? 
Well assembly programmers are weird ( Yes I have programmed in assembly languge for my sins, and yes I am weird for having done so )
The thing is, GOTOs don’t typically produce code that’s easier to understand. In some situations though, it can produce code that’s more efficient, with little or no change in readability.
It is admittedly easier to ban GOTOs altogether, especially when teaching novice programmers. This seldom produces any adverse effects. However, a more experienced programmer should know that there are rare instances where a GOTO can actually produce a performance benefit.
For more on the topic: Books | Steve McConnell
Of course, years from now, when someone else causes the system to crash, they will have a scapegoat- you to blame!