6 ms·

Can you give an example of where you've used goto in C or a C-like language? Or a rough estimate of the number of times you've found goto to be the best solutio

Can you give an example of where you've used goto in C or a C-like language? Or a rough estimate of the number of times you've found goto to be the best solution? I agree with your post in principle, but in practice I can't think of a single example where I've used a goto that wasn't eventually refactored to something better that didn't have the goto. Edit: Probably the most common example (and one given early in the article) is deeply nested loops. This is a good example of where I'm very unlikely to use goto. Almost certainly, I will prefer to hide one or more of the inner loops inside of a function call.

mumblemumble 5y ago
What's wrong with the examples in the article?
codr7 5y ago
https://github.com/codr7/ampl/blob/main/src/ampl/eval.cpp https://github.com/codr7/ampl/blob/main/src/ampl/eval.cpp
- InfiniteRand 5y ago
  I'm sure there's probably a reason for doing things this way, but it seems like that code would make more sense as a function pointer table and a series of functions. Was that not preferred for aesthetic reasons or for some specific technical reason?
  - codr7 5y ago
    Speed. Your suggestion adds indirect memory access plus function call, for every instruction. I've tried every other way I can think of, and nothing runs faster from my experience.
- slaymaker1907 5y ago
  Replying to infiniterand, a table of function pointers is going to generally have way more overhead than an indirect goto. An indirect goto is essentially a single assembly jump instruction. This is also often faster than a while loop plus switch since it is friendlier to the branch predictor.
InfiniteRand 5y ago
It's good for a simplified version of exception handling for C (granted C does have setjmp/longjmp but that's more like the complicated version of exception handling) If you hit an error condition in deeply nested logic and need to go to common error handling code or go to a recovery point, then goto makes sense. Often times in these scenarios simplifying the logic is also an option, but that isn't always the case, especially when dealing with external interfaces that have a lot of potential error conditions that cannot be dealt with easily from the immediate caller (I'm thinking primarily of system interfaces, but also potentially library interfaces). From what I've seen this is the only really good scenario for goto and I think the examples in the article more or less fall into this category of escaping from deeply nested error cases.
- brundolf 5y ago
  Makes me realize that the way some people use caught-exceptions is actually just reaching for goto in a language that doesn't have it
anfelor 5y ago
Another example not covered on the article is tail call optimisation. GCC is not very good at it and manually adding it using goto can sometimes speed code up by ~20%. Very useful when writing down a complex recursive algorithm that you can't easily express as a loop.
NtGuy25 5y ago
If you have a dispatcher or an infinite state machine, say an emulator. Or even just anything in general with cleanup, you use goto to "goto ERRORCLEANUP". So you have one exit condition to clean up. This is recommended in CERT c.
davidwf 5y ago
It's a very common pattern for C memory allocation checking. A public example I know off the top of my head can be seen here: https://github.com/zedshaw/learn-c-the-hard-way-lectures/blob/master/dbg.h https://github.com/zedshaw/learn-c-the-hard-way-lectures/blo... (the implementation of the CHECK macro). That's in a C tutorial but I've implemented a version of that macro frequently. Let's say you need to dynamically allocate two buffers in a function and want to make sure they are freed at the end of your call. You can use this macro like so: int two_bufs(int n, int m) { int *buf_1 = NULL; int *buf_2 = NULL; buf_1 = calloc(n, sizeof(int)); CHECK(buf_1); buf_2 = calloc(m, sizeof(int)); CHECK(buf_2); // ... lots of cool things with buf_1 and buf_2 error: free(buf_1); free(buf_2); // Safe if null }
- jefftk 5y ago
  You have "free(buf_2); // Safe if null", but if CHECK(buf_1) turns into a "goto error", won't buf_2 be uninitialized? And so can take on any value?
  - davidwf 5y ago
    You are correct, will edit. C is hard, writing C in the browser sans coffee is harder. :-)
    - jefftk 5y ago
      I do think this illustrates one of the issues with goto: normally the compiler would be able to warn that you were using buf2 potentially uninitialized, but I think you wouldn't get a warning in this case.
      - lilyball 5y ago
        The Clang Static Analyzer could probably find this, if the compiler itself doesn't notice.
      - Jtsummers 5y ago
        One of the examples in the linked article showed the compiler emitting a warning when a variable wasn't initialized because the goto skipped past that line, it's in 31.7. I don't know what compilers will or will not give you that warning, but at least the one used for the article does. So it ought to catch the problem with the initial version of the example above as well.
bodyfour 5y ago
> deeply nested loops. [...] I will prefer to hide one or more of the inner loops inside of a function call. And I would too... but sometimes there are too many local variables involved to do that cleanly. And, ultimately, if you are making your code less clean to avoid using a goto then you avoided unwisely. > Can you give an example of where you've used goto in C or a C-like language? Well there have been several fairly normal examples cited by others. Let me set out my stall and present a more controversial one. Suppose I have a switch() block (which is sorta a glorified goto already!) and I have two cases that have the same epilogue. For example: switch (get_next_thing_to_do()) { case ACTION_A: do_action_a(); goto common_post_action_cleanup; case ACTION_B: do_action_b(); common_post_action_cleanup: cleanup_something(); z = nullptr; x = x->next; // yadda yadda break; case ACTION_C: do_action_c(); // NOTE: we don't need to do the "cleanup" here break; } Now the first thing you should try is to put all of the shared code in its own function. Again, this isn't always practical if what you need to do effects a lot of local variables. It also means that those "cleanup" steps are now implemented far away from the rest of the logic which might hurt comprehensibility on its own. Another option is to just suck it up, repeat the code twice, and then just trust that the compiler will clean it up. First, that won't be as attractive if you have to do it 10 times instead of twice. Second, you're now violating the DRY principal which to me is sacrosanct. Experience has taught me that if someone updates the cleanup code for ACTION_A they will forget to update ACTION_B at the same time. If you care that the two cases always end with the same epilogue you need to have a single copy of the code. You can try to get back into compliance with DRY by using something like a C macro, but now you're not winning the war against ugly code. Finally you could just put the cleanup code after the switch(), either by retesting the enum value (requiring it to be stored in a temporary variable) or by adding some other new cleanup_needed boolean flag. But now we're adding control flow that wasn't there before. I personally believe that doesn't help readability or maintainability. You're now just adding more variables to understand and probably getting worse generated assembly to boot. While many programmers will look at this and feel vaguely icky about the presence of a "goto" if you really stop and look at the block of code it's actually quite readable...at least as long as the label and the goto are near each other. It is immediately apparent that two "states" are sharing some code and why. This little example is obviously made up. However I've spent a lot of my career writing things like hand-crafted state machines and situations exactly like this (where two "states" are different but share the same epilogue) comes up all the time. State machine code like this is famously hard to read but often sharing code via goto like this is the least-bad option for expressing non-hierarchical control flow.
jjtheblunt 5y ago
state machines a la finite automata, which (for examples) are generated by compiler parser generators like yacc ?
adrian_b 5y ago
Few programmers use goto, because they have been indoctrinated against it and they have no understanding about when goto is bad and when goto is good, but there are many cases where using goto is better (i.e. more clear and/or faster) than what most programmers write now in such occasions. In some of those cases there are alternatives that could be better than goto, but they cannot be used because they need features that are missing from the programming languages popular now. One example is state machines. Many programmers when having to implement a state machine use a state variable, e.g. an enumeration and a big "switch" or "case" structure, depending on the language, with a branch for each state. This kind of implementation follows the method taught now to avoid goto's by adding unnecessary variables that are used to store some state when some condition is detected with the purpose to make a jump later with an extra if or switch instead of doing a jump with a goto immediately when the condition has been detected. This method of eliminating goto's is pretty stupid, because it not only adds useless variables but it also doubles the number of conditional branches, because each if (condition) goto label; is replaced by: if (condition) variable = value; ... if (variable == value) {...} or switch (variable) {...} Besides the accesses to non-cached memory, the conditional branches are the main causes of low performance, so doubling the number of conditional branches can result in much worse performance. When the second conditional branch is a "switch", that is even worse, because it is typically implemented as an indexed jump, which will be frequently mispredicted. Instead of using a state variable and a "switch" with branches for states, the right implementation is to have sequences of statements for the states, with the first statement in each sequence labeled with the name of the state. During each state, when the condition for the transition to another state is detected, a goto is executed, with the name of the next state. Anyone who believes that this is less clear or more difficult to read than the variant with state variables is delusional, because in the variant with goto's you see immediately the effect of a transition condition, while in the variant with state variables you just see some value being stored and you do not know its purpose until possibly much later when you discover that it is tested for a second conditional branch. Even after you see this use, you are not certain that this is the only place where the variable is used, it might also have other uses and you might need extra time until you are certain about what the program really does. A more elegant solution for state machines is possible only in languages where tail call optimization is guaranteed. In such languages each state may be implemented as a separate function and the goto's may be replaced with function invocations in final positions, which are transformed by the compiler into jumps. While not so many programmers need to write state machines, there are much more frequent uses where goto is superior, e.g. for error management in cases where exceptions are inappropriate, but describing when, why and how would be long. In general all the problems for which goto was considered harmful are not solved by eliminating goto but by restricting its behavior. There was a series of research articles by various authors, published between 1970 and 1975, whose conclusion was that the right kind of goto should be allowed to make only forward jumps and that the labels must have a scope restricted to the block in which they are declared. Therefore a goto should be able only to exit from a block but not to enter a block. An example of a programming language that had this restricted form of goto was the language Mesa, from Xerox. In C however, it would not be possible to restrict goto only to forward jumps without simultaneously adding guaranteed tail call optimization.
jjav 5y ago
Think of everythin which in java you would put in the catch and finally blocks. Those are nearly always most cleanly handled in C code by doing a goto to the cleanup/return section at the end of the function. You could work around this via tons of deeply nested blocks, but that makes the code very unreadable. The goto cleanup pattern makes the code intuitive and very readable. I still have a printout somewhere of an application from the 80s, maybe a dozen pages in small font, every few lines it jumps via goto to somewhere else, depending on state (global variables, of course). It was a serious nightmare to figure out where the code is going. That was the historical context of "goto considered harmful". It sure was! Code like that doesn't exist today, the lessons have been learned. It had nothing to do with clean jump to a cleanup section (which is what a finally{} block is, after all).
deleted 5y ago
[deleted]
throwaway09223 5y ago
There's a good real world example of goto for progressive cleanup here: https://github.com/square/pam_krb5_ccache/blob/master/pam_krb5_ccache.c#L50-L210 https://github.com/square/pam_krb5_ccache/blob/master/pam_kr...
idiocrat 5y ago
The times I found I used the goto statements are retrials. For example, if a file is locked for writing, I want to wait for 5, then 10, then 15 seconds, retrying each time, before giving up. In such case I do not want the retrials loop to be my main control structure. Instead, I jump from inside the IO exception catch block to the ReTry label, restarting the whole operation. This makes the flow fairly clean.
throwawaylinux 5y ago
The Linux kernel has 28 million lines of C code, and 180 thousand goto statements. 1 every 160 lines is a goto, and that's just a naive count so includes all header and preprocessor gunk, whitespace, some generated C code, comments, etc. If you're talking about more pure lines if C, it would probably be close to 1% of statements are goto. It might not be everyone's cup of tea as the pinnacle of C programming, but it's a real highly used medium-large project that has coped well with a pretty high rate of change from a very wide spectrum of contributors. So it is a good real world example of open C code you can look at that is maintainable while making a lot of use of goto.
GrumpyYoungMan 5y ago
There are a few decent examples given by the Linus kernel devs on a LKML thread where an unfortunate soul wandered in and suggested that they refactor to get rid of GOTOs: https://lkml.org/lkml/2003/1/12/126 https://lkml.org/lkml/2003/1/12/126 > "I will prefer to hide one or more of the inner loops inside of a function call." That risks the additional unnecessary overhead of a function call, which can be expensive in a loop, and not all compilers are as good at optimizing as they should be.
ghoward 5y ago
For a rough estimation, you can use my bc at [1] which uses goto extensively for safe and effective use of setjmp() and longjmp(), while having no memory leaks (to my knowledge). When going through the code, though, be aware that some goto's are in #define's to make it easier to work with setjmp(). If you're lazy, it's about 10k loc with about 100-200 uses of goto. [1]: https://git.yzena.com/gavin/bc https://git.yzena.com/gavin/bc

mumblemumble 5y ago

What's wrong with the examples in the article?

codr7 5y ago

https://github.com/codr7/ampl/blob/main/src/ampl/eval.cpp https://github.com/codr7/ampl/blob/main/src/ampl/eval.cpp

InfiniteRand 5y ago
I'm sure there's probably a reason for doing things this way, but it seems like that code would make more sense as a function pointer table and a series of functions. Was that not preferred for aesthetic reasons or for some specific technical reason?
- codr7 5y ago
  Speed. Your suggestion adds indirect memory access plus function call, for every instruction. I've tried every other way I can think of, and nothing runs faster from my experience.
slaymaker1907 5y ago
Replying to infiniterand, a table of function pointers is going to generally have way more overhead than an indirect goto. An indirect goto is essentially a single assembly jump instruction. This is also often faster than a while loop plus switch since it is friendlier to the branch predictor.

InfiniteRand 5y ago

It's good for a simplified version of exception handling for C (granted C does have setjmp/longjmp but that's more like the complicated version of exception handling) If you hit an error condition in deeply nested logic and need to go to common error handling code or go to a recovery point, then goto makes sense. Often times in these scenarios simplifying the logic is also an option, but that isn't always the case, especially when dealing with external interfaces that have a lot of potential error conditions that cannot be dealt with easily from the immediate caller (I'm thinking primarily of system interfaces, but also potentially library interfaces). From what I've seen this is the only really good scenario for goto and I think the examples in the article more or less fall into this category of escaping from deeply nested error cases.

brundolf 5y ago
Makes me realize that the way some people use caught-exceptions is actually just reaching for goto in a language that doesn't have it

anfelor 5y ago

Another example not covered on the article is tail call optimisation. GCC is not very good at it and manually adding it using goto can sometimes speed code up by ~20%. Very useful when writing down a complex recursive algorithm that you can't easily express as a loop.

NtGuy25 5y ago

If you have a dispatcher or an infinite state machine, say an emulator. Or even just anything in general with cleanup, you use goto to "goto ERRORCLEANUP". So you have one exit condition to clean up. This is recommended in CERT c.

davidwf 5y ago

It's a very common pattern for C memory allocation checking. A public example I know off the top of my head can be seen here: https://github.com/zedshaw/learn-c-the-hard-way-lectures/blob/master/dbg.h https://github.com/zedshaw/learn-c-the-hard-way-lectures/blo... (the implementation of the CHECK macro). That's in a C tutorial but I've implemented a version of that macro frequently. Let's say you need to dynamically allocate two buffers in a function and want to make sure they are freed at the end of your call. You can use this macro like so: int two_bufs(int n, int m) { int *buf_1 = NULL; int *buf_2 = NULL; buf_1 = calloc(n, sizeof(int)); CHECK(buf_1); buf_2 = calloc(m, sizeof(int)); CHECK(buf_2); // ... lots of cool things with buf_1 and buf_2 error: free(buf_1); free(buf_2); // Safe if null }

jefftk 5y ago
You have "free(buf_2); // Safe if null", but if CHECK(buf_1) turns into a "goto error", won't buf_2 be uninitialized? And so can take on any value?
- davidwf 5y ago
  You are correct, will edit. C is hard, writing C in the browser sans coffee is harder. :-)
  - jefftk 5y ago
    I do think this illustrates one of the issues with goto: normally the compiler would be able to warn that you were using buf2 potentially uninitialized, but I think you wouldn't get a warning in this case.
    - lilyball 5y ago
      The Clang Static Analyzer could probably find this, if the compiler itself doesn't notice.
    - Jtsummers 5y ago
      One of the examples in the linked article showed the compiler emitting a warning when a variable wasn't initialized because the goto skipped past that line, it's in 31.7. I don't know what compilers will or will not give you that warning, but at least the one used for the article does. So it ought to catch the problem with the initial version of the example above as well.

bodyfour 5y ago

> deeply nested loops. [...] I will prefer to hide one or more of the inner loops inside of a function call. And I would too... but sometimes there are too many local variables involved to do that cleanly. And, ultimately, if you are making your code less clean to avoid using a goto then you avoided unwisely. > Can you give an example of where you've used goto in C or a C-like language? Well there have been several fairly normal examples cited by others. Let me set out my stall and present a more controversial one. Suppose I have a switch() block (which is sorta a glorified goto already!) and I have two cases that have the same epilogue. For example: switch (get_next_thing_to_do()) { case ACTION_A: do_action_a(); goto common_post_action_cleanup; case ACTION_B: do_action_b(); common_post_action_cleanup: cleanup_something(); z = nullptr; x = x->next; // yadda yadda break; case ACTION_C: do_action_c(); // NOTE: we don't need to do the "cleanup" here break; } Now the first thing you should try is to put all of the shared code in its own function. Again, this isn't always practical if what you need to do effects a lot of local variables. It also means that those "cleanup" steps are now implemented far away from the rest of the logic which might hurt comprehensibility on its own. Another option is to just suck it up, repeat the code twice, and then just trust that the compiler will clean it up. First, that won't be as attractive if you have to do it 10 times instead of twice. Second, you're now violating the DRY principal which to me is sacrosanct. Experience has taught me that if someone updates the cleanup code for ACTION_A they will forget to update ACTION_B at the same time. If you care that the two cases always end with the same epilogue you need to have a single copy of the code. You can try to get back into compliance with DRY by using something like a C macro, but now you're not winning the war against ugly code. Finally you could just put the cleanup code after the switch(), either by retesting the enum value (requiring it to be stored in a temporary variable) or by adding some other new cleanup_needed boolean flag. But now we're adding control flow that wasn't there before. I personally believe that doesn't help readability or maintainability. You're now just adding more variables to understand and probably getting worse generated assembly to boot. While many programmers will look at this and feel vaguely icky about the presence of a "goto" if you really stop and look at the block of code it's actually quite readable...at least as long as the label and the goto are near each other. It is immediately apparent that two "states" are sharing some code and why. This little example is obviously made up. However I've spent a lot of my career writing things like hand-crafted state machines and situations exactly like this (where two "states" are different but share the same epilogue) comes up all the time. State machine code like this is famously hard to read but often sharing code via goto like this is the least-bad option for expressing non-hierarchical control flow.

jjtheblunt 5y ago

state machines a la finite automata, which (for examples) are generated by compiler parser generators like yacc ?

adrian_b 5y ago

Few programmers use goto, because they have been indoctrinated against it and they have no understanding about when goto is bad and when goto is good, but there are many cases where using goto is better (i.e. more clear and/or faster) than what most programmers write now in such occasions. In some of those cases there are alternatives that could be better than goto, but they cannot be used because they need features that are missing from the programming languages popular now. One example is state machines. Many programmers when having to implement a state machine use a state variable, e.g. an enumeration and a big "switch" or "case" structure, depending on the language, with a branch for each state. This kind of implementation follows the method taught now to avoid goto's by adding unnecessary variables that are used to store some state when some condition is detected with the purpose to make a jump later with an extra if or switch instead of doing a jump with a goto immediately when the condition has been detected. This method of eliminating goto's is pretty stupid, because it not only adds useless variables but it also doubles the number of conditional branches, because each if (condition) goto label; is replaced by: if (condition) variable = value; ... if (variable == value) {...} or switch (variable) {...} Besides the accesses to non-cached memory, the conditional branches are the main causes of low performance, so doubling the number of conditional branches can result in much worse performance. When the second conditional branch is a "switch", that is even worse, because it is typically implemented as an indexed jump, which will be frequently mispredicted. Instead of using a state variable and a "switch" with branches for states, the right implementation is to have sequences of statements for the states, with the first statement in each sequence labeled with the name of the state. During each state, when the condition for the transition to another state is detected, a goto is executed, with the name of the next state. Anyone who believes that this is less clear or more difficult to read than the variant with state variables is delusional, because in the variant with goto's you see immediately the effect of a transition condition, while in the variant with state variables you just see some value being stored and you do not know its purpose until possibly much later when you discover that it is tested for a second conditional branch. Even after you see this use, you are not certain that this is the only place where the variable is used, it might also have other uses and you might need extra time until you are certain about what the program really does. A more elegant solution for state machines is possible only in languages where tail call optimization is guaranteed. In such languages each state may be implemented as a separate function and the goto's may be replaced with function invocations in final positions, which are transformed by the compiler into jumps. While not so many programmers need to write state machines, there are much more frequent uses where goto is superior, e.g. for error management in cases where exceptions are inappropriate, but describing when, why and how would be long. In general all the problems for which goto was considered harmful are not solved by eliminating goto but by restricting its behavior. There was a series of research articles by various authors, published between 1970 and 1975, whose conclusion was that the right kind of goto should be allowed to make only forward jumps and that the labels must have a scope restricted to the block in which they are declared. Therefore a goto should be able only to exit from a block but not to enter a block. An example of a programming language that had this restricted form of goto was the language Mesa, from Xerox. In C however, it would not be possible to restrict goto only to forward jumps without simultaneously adding guaranteed tail call optimization.

jjav 5y ago

Think of everythin which in java you would put in the catch and finally blocks. Those are nearly always most cleanly handled in C code by doing a goto to the cleanup/return section at the end of the function. You could work around this via tons of deeply nested blocks, but that makes the code very unreadable. The goto cleanup pattern makes the code intuitive and very readable. I still have a printout somewhere of an application from the 80s, maybe a dozen pages in small font, every few lines it jumps via goto to somewhere else, depending on state (global variables, of course). It was a serious nightmare to figure out where the code is going. That was the historical context of "goto considered harmful". It sure was! Code like that doesn't exist today, the lessons have been learned. It had nothing to do with clean jump to a cleanup section (which is what a finally{} block is, after all).

deleted 5y ago

[deleted]

throwaway09223 5y ago

There's a good real world example of goto for progressive cleanup here: https://github.com/square/pam_krb5_ccache/blob/master/pam_krb5_ccache.c#L50-L210 https://github.com/square/pam_krb5_ccache/blob/master/pam_kr...

idiocrat 5y ago

The times I found I used the goto statements are retrials. For example, if a file is locked for writing, I want to wait for 5, then 10, then 15 seconds, retrying each time, before giving up. In such case I do not want the retrials loop to be my main control structure. Instead, I jump from inside the IO exception catch block to the ReTry label, restarting the whole operation. This makes the flow fairly clean.

throwawaylinux 5y ago

The Linux kernel has 28 million lines of C code, and 180 thousand goto statements. 1 every 160 lines is a goto, and that's just a naive count so includes all header and preprocessor gunk, whitespace, some generated C code, comments, etc. If you're talking about more pure lines if C, it would probably be close to 1% of statements are goto. It might not be everyone's cup of tea as the pinnacle of C programming, but it's a real highly used medium-large project that has coped well with a pretty high rate of change from a very wide spectrum of contributors. So it is a good real world example of open C code you can look at that is maintainable while making a lot of use of goto.

GrumpyYoungMan 5y ago

There are a few decent examples given by the Linus kernel devs on a LKML thread where an unfortunate soul wandered in and suggested that they refactor to get rid of GOTOs: https://lkml.org/lkml/2003/1/12/126 https://lkml.org/lkml/2003/1/12/126 > "I will prefer to hide one or more of the inner loops inside of a function call." That risks the additional unnecessary overhead of a function call, which can be expensive in a loop, and not all compilers are as good at optimizing as they should be.

ghoward 5y ago

For a rough estimation, you can use my bc at [1] which uses goto extensively for safe and effective use of setjmp() and longjmp(), while having no memory leaks (to my knowledge). When going through the code, though, be aware that some goto's are in #define's to make it easier to work with setjmp(). If you're lazy, it's about 10k loc with about 100-200 uses of goto. [1]: https://git.yzena.com/gavin/bc https://git.yzena.com/gavin/bc