(Assuming C, here). Anytime I need a goto, I have functions. That's what they're there for essentially. This not only allows you to move to a different address, but it also maximizes re-usability; a topic I seem to have missed being discussed. Clean-up for malloc/free will be the same regardless how you use it, so why not write your own little library to handle it for you? Goto, while making it simple and readable (I guess... but not using it ever, I can honestly say functions are far more readable for me) just shows to me that you're not thinking for the long term with your code.

I've said it before, and I'll say it again: There is absolutely no viable use case for goto in my working environment (C# 4).

If you have a for loop inside a for loop, you should avoid using break or continue and instead be perfectly explicit by using a goto.

I responded "very rarely."

At my job we still have some old applications originally written in Visual Basic 6, whose rudimentary exception handling was done using the "On Error GoTo LABEL" construct. You could conceivably implement try/catch/finally using it, but was never pretty. The coder had to ensure that they were branching to the Finally code and resuming the execution when the error is handled. Also, because these were just labeled sections of code, you didn't get a new scope, so RAII wasn't a possibility in your handlers.



' This routine will raise a stack overflow error
Sub KillMe
KillMe
End Sub

Sub DoStuff
' Set up error handler
On Error Goto Catch

' Stack overflow here:
KillMe
Exit Sub ' This guards against the program stepping into the error handler when there was no error

Catch:

Dim ErrorNumber


' Keep the error code because it will be clobbered when we switch off error handling
ErrorNumber = Err.Number

' Turn off error handler
On Error GoTo 0
If ErrorNumber = 0 Then
' Here's where your "catch" code would be
GoTo Finally
Else If ErrorNumber = 1 Then
' Or here...
GoTo Finally
End If

' Couldn't handle the error. Exit the program
End

Finally:
' Returns execution to the line after the line that caused the error
Resume Next
End Sub



I work mostly with C++, objective C or other languages that are not "pure C".
I never had the need to use a goto statement, the reason is that there are usually other ways to do things, at least in these languages. So, goto statements never really cross my mind as alternatives anyway.

The thing about goto statements is that they are easy for the computer to understand, after all, when code is compiled into assembly language, everything becomes a bunch of goto (jump) statements (basically, yeah, in assembly language, goto is the only way to go. See what I did there?).
However, we humans are more prone to messing up when doing a goto statement.

I don't think using goto is necessary, at least in the languages that I use. But if it really makes you feel better (or worse?), remember that your code will eventually be compiled into more goto statements than you can imagine.