Yes - a thousand times yes!

The goto has gotten a bad rap over the years because of Dijkstra's paper. And that paper has unduly influenced a lot of incorrect thinking. There are valid use cases for goto, and this is certainly one of them.

I use it all the time like the example above. Particularly because it makes my life so much easier when developing and debugging embedded C code across various tool chains, some of which have less functionality than others.

[edit - correct typo on Ed's name]

Just curious, not a C developer by any means, but why wouldn't you use a function here instead of a goto? I'm confused how goto would reduce error/improve readability in that example.

Again, not criticizing, genuinely want to know.

Simply: a goto never returns while a function call returns to where it was called from.

So specifically in the example above, if you called failure-handling functions instead of using goto's then when the function returned you would continue execution on the next line after the function call. In the example above, that's clearly not what you want.

Now you could add some else's after the function calls to prevent execution from continuing. i.e. to get to the appropriate step in the free_* sequence at the bottom, but that starts to look messy. So I have to admit (not being a goto-lover), the above example reads very nicely.

It conforms to the "gotos might be okay if they only jump forward" rule of thumb I've heard.

I've also seen extensive use of gotos for exception handling in C. After the knee-jerk reaction ("...but but Dijkstra!") I came to appreciate it as a useful idiom.

To be fair, Dijkstra said "harmful", not "forbidden". He was also talking about encouraging structured procedural programming rather than a game of Who's Clever Enough to Follow the Spaghetti.

We do things that are harmful all the time, in limited appropriate situations. Cutting into your abdomen is harmful, but a skillfully used surgeon's scalpel can fix a bigger problem. That's not license to go roll around on a pile of jagged, rusty steel scrap. Missing sleep is harmful, but if you do it once in a while to keep your job or to escape a nighttime flash flood then it's helpful.

Dijkstra was intending to set the norm from which people should mindfully and occasionally deviate. The point wasn't to ban the use of labelled jumps entirely.

GKH somewhere explained that they accept gotos that don't go back (leads to mess) only gotos that jump forward in function. Nice rule.

This looks fine to me. I wonder if C/C++ could be improved by introducing a new keyword `bail` which is the same as `goto` but is only allowed to jump to the bottom of the function. That way, codebases can outlaw `goto` but keep `bail`.

Are you looking for "return"?

With C++ you can ensure that you have your destructors do the tidy up, e.g. a messy example

struct cleaner { cleaner(string *toCleanup) : m_x(toCleanup) { } ~cleaner() { delete m_x; m_x = nullptr; } };

Yup, C++ has autocleanup. Of course if you are using fopen() instead something more modern you'll need to fclose(). Adding a new keywords to C is a long shot. Perhaps compilers could detect non-cleanup use of goto and give it a warning.

A typical C++ codebase I'm working on these days would have scope guards implemented via macros, such that you can do e.g.:

    FILE* f = fopen(...);
    SCOPE_GUARD({ fclose(f); });

This is mainly used for one-off calls to some native API, where writing a proper RAII wrapper for the managed resource is not worth it.

In a previous job where I wrote C code, I had a macro named "bail" that pretty much did that: log an error message, then jump to the cleanup section of the function.

Wouldn't it be better to have some sort of linter tool do this? Why create a more specific language construct when you already have one?

I'd much rather see that as a state machine.

How common is it to add "exception macros"? Something like:

"error(handle, "could not open handle", free_something)"