GOTOphobia considered harmful in C

The thing is that many people today have never encountered the sort of spaghetti code that Dijkstra was talking about in 1968. There's plenty of confusing and messy code around, but true spaghetti code that GOTOs all over the place and is nigh-impossible to follow has been extremely rare for a long time. I can't recall encountering it in the last 30 years.

It easy to misunderstand what he was even talking about because the paper is so short, assumes you know about this context, and has no concrete examples. People quite reasonably assume it's about ugly code they've encountered, but it's actually about ugly code of a completely different kind.

I'm not that old, but I was unlucky enough to have programmed in an unstructured language where GOTO was the only way to use faux-subroutines in my teens. Whatever you think as code that's difficult to follow: it's nothing compared to this.

Sure, it's a good letter, and indeed it's about this problem where people use a go-to or jump control flow with no structure whereas by the time he wrote that letter there were well understood structures (like: functions) to prefer.

However, while I sympathise with a C programmer who feels goto is necessary in their language, I think that speaks to a problem in the language rather than the programmer. If you have better structural support in your language you can express the things the author (of the link, not Dijkstra) wants to express without needing this unstructured go-to.

For example Rust's break 'label value; allows us to mark any compound expression with the 'label, and then say from anywhere inside that expression but nowhere else that we've decided the value of the expression overall and here's what it is.

This doesn't feel that different from what is being done here with goto, except for two crucial things as a result of being structured:

1. Rust will type check this, if this region of the program picks a Dog, our break needs to provide a Dog, it can't just shrug and expect the program to continue without one. This means maintenance programmers don't need non-local reasoning, this region of the program does, in fact, always pick a Dog, albeit the break 'label value is something to look closely at if you're reading that region itself.

2. We cannot do this, even by mistake (e.g. as a result of copy-paste) across scopes. If you try to break 'label result from the cat care loop into the dog loop earlier in the same function, that just doesn't compile, whereas the C goto has no problem attempting that (a good C compiler should notice if you try to do something really egregious, but good luck).

Interestingly, many seem to want to project their own opinion upon Dijkstra.

Dijkstra is clearly arguing for a “single entry single exit” style. But modern consensus seem to uphold single entry but accept multiple exits from a block. Break, continue, early returns, exceptions - all are example of multiple exit. These are more constrained than gotos but nevertheless Dijkstras argument applies to them also.

I personally belive early returns can greatly improve readability (when not nested too deep) an that exceptions are typically cleaner than the alternative. But I acknowlede Dijkstra would disagree.

[1] on structured concurrency gives good context for Dijkstra's GOTO paper and how it is applicable today.

[1] https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

> It's better when the lexical structure of the source code maps to the execution structure.

Sure, but that has nothing to do with whether the GOTO statement should be used. The semantics of GOTO are arguably quite clear; they amount to setting a different continuation for the running program. (Semantically, this implies that the precondition of the GOTO statement is made a possible precondition for the label that the statement jumps to; and execution simply does not proceed to the next statement.)

There are even "relooper" algorithms to reconstruct a structured program from patterns in the idiomatic use of GOTO statements: they are used in compiling to structured object languages such as WASM code. Using GOTOs in an idiomatically sensible way (avoiding spaghetti code) may be less readable than writing actual structured blocks, but only slightly so.

That wasn’t even Dijkstra’s title. It was Niklaus Wirth who edited the title in. I mention that in Street Coder.

And the original paper is published even before the first version of C was introduced.

This is one of those problems that Tail Call Elimination cleanly addresses. The "obvious" approach to writing an FSM does exactly what you'd expect.

Where in the world beginners use state machines instead of switch statement or if ladder?

this is genuine question, because I do believe that people do not use enough state machines to model their systems.

I don't think it's essential. I think it can be a reasonable choice, but there are other patterns that can accomplish the same thing, with some upsides and some downsides: https://gist.github.com/oconnor663/b0b32f25301ed5a1af4d07053...

Not really, I have deployed plenty of C code into production and never used gotos, other than special flavoured gotos like UNIX signals.

My problems have always been in how memory corruption friendly C happens to be, nothing to do with how to use structured programming practices for resource cleanup.

of course nobody should be writing C any more, for exactly the reason you're demonstrating in this comment

This is one of those half-true claims that C++ aficionados make, probably because they can play a bit fast and loose with resource cleanup in their particular situations.

RAII simplifies some of the resource cleanup, but at a cost: if the resource cleanup fails, there’s essentially no way to convey this.

So yes, you can write a destructor that tries to clean up your resources regardless of how the code exits its current scope. But if that cleanup encounters a problem, the destructor can, at best, try to convey this indirectly, either by (commonly) logging or (rarely) setting a variable to a value. It certainly cannot throw another exception, or even directly manipulate the return value of the function.

This is fine for some purposes, and completely unacceptable for others. But it’s not equivalent to the explicit cleanup and error handling in C.

So some of us occasionally find ourselves in an RAII language and using goto.

Even with RAII in C++, goto is still useful for handling the occasional error case where you need to reset/retry some operation e.g. due to transient hardware issues that are not unrecoverable errors. A common example that comes to mind immediately is asynchronous disk reads where the data was corrupted during transfer but may succeed if transparently cleaned up and re-issued.

I use goto rarely. But there are times when anything else would be inelegant, and in those instances I'll use it without hesitation.

> [0] C++, Rust, Go, or anything else with automatic memory management and destructors

Go's automatic memory management (GC) doesn't come in to play here, but the defer statement does. It doesn't make Go a RAII language, but it makes Go a language with a nicer "run this code at the end of the stack frame" feature than goto.

> In RAII languages[0], you obviously don't need unrestricted gotos.

You don't need them for teardown, but they still make sense for retries -- cases where a procedure needs to start over after hitting certain branches, e.g. a transaction conflict. I think `goto retry` is a lot more readable than wrapping the procedure in `do { ... } while (false)` and using `continue` to retry.

`goto` works very nicely with RAII here in that it'll invoke the destructors of any local variables that weren't declared yet at the point being jumped back to.

> Labeled break and continue ...

I find that normally if I need nested break then it suffices to refactor the target loop into a function and use return instead.

I don't think I normally miss multilevel continue, but the same strategy would work for that too. You'd just pull out the target loop body rather than the whole loop.

If that doesn't work because you need to select too many different break/continue levels (more than two) then maybe it's time to review the complexity of the function anyway.

Go doesn't have RAII or destructors, it has defer.

I find that after writing a lot of Go, manually having to defer/scope(exit) is a lot more error prone than just RAII destructors: it’s impossible to forget to defer the destructor.

I have a distaste for all of these examples, which comes from the existence of a side-effecting operation: calling do_something() necessitates the need to call a cleanup function, which means there's some state being changed but hidden behind the internals of these methods. It is really easy to call this incorrectly which says to me it's just a badly-designed API.

In C# the idiomatic way would be to have each of these 3 things be defined in a class using IDisposable, which is similar to D's scope() -- the declaring class gets a cleanup method when the variable goes out of scope, no matter how that happens.

I assume there's some interaction between these classes, but IMHO that should be explicitly defined and so the code would look something like:

    public void foo(int bar) {
        using var something = new Something(bar)
        if (something.do()) {
            using var stuff = new Stuff(bar);
            if (stuff.init()) {
                using var stuff2 = new Stuff2(bar); // two "stuff"s looks dumb but this is example code
                if (stuff2.prepare()) {
                    return do_the_thing(something, stuff, stuff2, bar);
                }
            }
        }

        return null;
    }

There's actually several ways to structure this code which would result in something that looks better than the above, but being example code and not knowing how `something` and `stuff` interact, it's hard to write this nicely. I'd probably aim for something much more concise like:

    public void foo(int bar) {
        using var something = new Something(bar);
        using var stuff = new Stuff(something);
        using var stuff2 = new Stuff2(stuff);

        return stuff2.prepare() ? do_the_thing(stuff2) : null;
    }

In the above, I assume stuff2.prepare() calls everything it needs to on the dependent objects, but how I'd structure this for real entirely depends on what they're actually doing.

Plain C version with attribute((__cleanup)):

    int* foo(int bar) {
        int* return_value = NULL;

        __cleanup__((cleanup_1)) int c1 = 0;
        if (!do_something(bar))
            return NULL;
        __cleanup__((cleanup_2)) int c2 = 0;
        if (!init_stuff(bar))
            return NULL;
        __cleanup__((cleanup_3)) int c3 = 0;
        if (!prepare_stuff(bar))
            return NULL;
        return_value = do_the_thing(bar);

        return return_value;
    }

Do scopes work without linking against the D runtime?

It's still wrong by default.

The correct pattern here is RAII, which requires no explicit cleanup code so there's no forgetting to use it.

GOTO is like profanity: it can be useful when done sparingly, but your peers will start judging you if you rely on it too often.

This has been called the https://en.wikipedia.org/wiki/Rule_of_least_power, and it’s a good way to make legible what you’re doing and especially to exclude what you aren’t doing.

This is false. Tail recursion is clearer and easier to reason about than loops, and tail recursion can be rewritten into gotos. I mean rewritten in a direct way, where the shape of the logic is the same.

E.g. even an odd problem. Let's use GNU C with local functions:

  #include <stdbool.h>

  bool even(int x)
  {
    auto bool odd(int x);
    bool even(int x)
    {
      if (x == 0)
        return true;
      else
        return odd(x - 1);
    }
    bool odd(int x)
    {
      if (x == 0)
        return false;
      else
        return even(x - 1);
    }

    return even(x);
  }

Using goto: achieved by a mechanical transformation involving just some local edits:

  bool even(int x)
  {
    goto start;

    even:
    {
      if (x == 0)
        return true;
      else
      {
        x = x - 1;
        goto odd;
      }
    }
    odd:
    {
      if (x == 0)
        return false;
      else
      {
        x = x - 1;
        goto even;
      }
    }

    start: goto even;
  }

Every tail-called local function just becomes a block headed by a goto label. The tail call is replaced by assigning a new value to every argument variable and performing a goto. Someone who is briefed on the approach here can easily see the original tail recursion and maintain the code in such a way that the tail recursion could always be recovered from it.

There was a discussion several years ago in comp.lang.c where a problem was proposed: using whatever approach you see fit, write a C program which strips comments from C code, but preserves everything, including preprocesor directives. Something like that. The person who proposed the problem refrained from posting his solution for several days. He used tail recursion for the entire state machine of the thing (even avoiding if statements; all the cases in the tail functions were handled by the ternary ?: operator).

Others used structured programming: nested loops and such. My solution used goto.

I argued that the goto solution had all the good properties of the superior tail calling solution.

I then supported my argument by writing a text filter which converted that person's tail call program into one with a big function containing goto blocks (compiling and producing the same result and all). A reverse filter would be possible also.

I believe that we can take any mess of a goto graph, divide it into the labeled nodes, round up the variable and everything being done to them and express it as tail recursion. Ironically, the one thing that will make it a bit harder is structured control flow constructs like while, for, switch and what not, where we may have to rewrite those to explicit goto first! E.g. if we look at a while loop, it's like a tail call, but one which is invisible. The end of the while loop body invisibly tail calls to the start, which is bad for understanding.

The thing that will detract from the ability to understand the tail call graph is excessive parameters. In the worst case, every tail function will have to take all of the state variablews as parameters, and pass them all to the next tail function (except for altering some of them). There is a pass that can be done over that to reduce some of these. Like if some tail function foo(a, b, c, d, e, f) doesn't do anything wiht c d e f other than pass it to children and none of those children do anything with those variables (transitively), we can cull those parameters from foo and all the children. This is the hard thing to understand in goto graphs: which of the numerous state variables are relevant to where the goto is going?

Some state vars can be replicated and localized. E.g. in our even() example, we can do this:

  bool even(int x)
  { 
    // params of even:
    int x0;
    // params of odd
    int x1;

    goto start;

    even:
    {
      if (x0 == 0)
        return true;
      else
      {
        x1 = x0 - 1;
        goto odd;
      }
    }
    odd:
    {
      if (x1 == 0)
        return false;
      else
      {
        x0 = x1 - 1;
        goto even;
      }
    }

    start:
    {
      x0 = x;
      goto even;
    }
  }

Now we no longer have the same variable on both sides of an assignment. Each block works with its private parameter variable. The other block only every assigns to that variable when simulating parameter passing: e.g. the odd block assigns to even's x0 just before goto even.

We can start with a goto graph and make incremental improvements like this and recover a tail call graph. We can then try to understand what the tail functions mean in terms of recursion and document that.

Or even oksofar = oksofar && do_something() to do away with the cumbersome ifs.

I don't like the code pattern if ( false == func() ). Function func() already returns a boolean, no need to compare that to a second boolean (false or true) to generate a third boolean.

Sorry, a little off topic I know.

At this point couldn't you just write an actual function and use "return"?

> I know for C it’s unthinkable to standardize such a luxury like defer or destructors, so we’re going to relive arguments from 1968 for as long as C is used.

There was a proposal for defer in C23 but it didn't make the cut [1]. There is also the __cleanup__ attribute if you're using GCC.

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2895.htm

Sorry I’m still not going to use Rust

> The nested functions usually get inlined by the compiler, so there is no cost to them.

This kind of code typically gets written when ‘usually’ isn’t good enough (of course, once you use a compiler, in theory, there are no guarantees; the compiler could compile the inlined-function one with a goto or vice versa, but programmers typically are more concerned about what happens in practice)

The inlined functions also may increase code size and instruction cache pressure.

On the other hand, having a branch less may be beneficial.

gcc supports nested functions. I like them lots.

They seem to generate a lot of hate though.

Only some goto use cases.

Returns are also gotos then.

It's not GOTOphobia. It's people blindly doing what others are telling them to do (or not to do) without the ability to critically think about what they're being told.

Lots of people just follow whatever anyone, who they perceive as authority, says. Critical thinking isn't a common trait.

I see this "if you're good then you don't need safety" mentality in a lot of conversations with C programmers about programming languages.

Maybe it's some kind of defencive response against newer programing languages slowly eating up spaces C used to be dominant in (like command line tools and system daemons), maybe it's just the programmer saying this thinking they're that special. Either way, most people saying this are setting themselves up for failure.

I wouldn't start a new project in C unless I absolutely have to but if you disagree, you can at least admit that there are dangers in C that you need help with if you want to be sure you're doing everything right. With most warnings treated as errors, extended warnings enabled, linting to make things like missing brackets obvious, static analysis of all code to spot difficult bugs, automated dynamic analysis of test cases and a proper testing pipeline I believe you can write C code that's safe enough.

In this case, I'm willing to give the authors the benefit of the doubt because goto hatred is worse than the risk posed by goto in most settings. Gotos used right are fancy if/switch statements and avoiding them in C can lead to a mess that doesn't add much safety. Most examples given are better in my opinion, because using goto can replicate the code flow modern languages provide with things like when/match/defer keywords.

This analogy implies that all other tools are 1000% safer, but they are not. In C it’s like pointing to a dusty corner behind a table in a room full of dirt.

When was the last time you did “cut your arm” with goto specifically? What’s the count and time ratio to other issues? Were these also addressed as taboo or left as “experience earned”? Gotophobia in its largest part is just a stupid meme with no real world data.

It's right up there with being told you shouldn't need any access to production if you programmed it correctly the first time.

Yeah, I don't know how people say stuff like this without looking over their shoulder or knocking on wood.

You monster.

I like you!

“Goto fail” would have been wrong in a non-goto language that use RAII.

The problem was not goto, it was that the else path was also “give up”. In a non goto/RAII/defer language it would have been something like

    If (error)
        Return
        Return

My assumption has been this was some kind of merge error rather being wrong off the bay. Interestingly mandatory indenting or mandatory braces might have stopped this, but then i would have thought -Werror with the dead code warnings would have as well :-/

But again the error was not the goto, and believing it was is the exact problem the article is talking about: people are so opposed to goto they are unable to see real issues (I have seen C code that tries to avoid goto completely and error handling code becomes horrific, far more complex, and far more error prone that just using goto). The problem with goto is that it is very easy to use it unnecessarily, in ways that complicated control flow but don’t actually make things better.

I’d say this was more due to the case not being properly enclosed in brackets.

Many people seem to really dislike using the brackets but this is what that gets you.

That error is not due to goto, it was just a goto which was errously executed because of badly formatted code. (It looked like the statement was inside an if-block due to the indent.)

Pyhon would have prevented this bug, but so would a formatter. Rust also requires braces for if-blocks to prevent this kind of error.

that one in particular was not really caused by goto, but rather by braceless if statements, it'd be a vulnerability all the same if the line was a "fail" function that was called instead of a goto.

This seems to be more an issue with if statements without curly braces.

I wondered then if this couldn't have been a merge error.

if considered harmful

C# (and Go) have adjusted goto to ensure consistent scoping, avoiding undefined variables, and keeping control flow reducible. So its a much safer and better form of goto than exposed in C/C++, where you can still do weird things without being warned by the language

Yes, because they multiply state.

I’m curious what you are calling that can cleanup local variables and temporaries?

Would you say that the Linux kernel is written by mostly "100% subpar C programmers"? Because it's an extremely common pattern to have multiple goto labels at the end of a function.