Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
Programming

Empirical Study On How C Devs Use Goto In Practice Says "Not Harmful" 677

Edsger Dijkstra famously opined in 1968 on the danger of Goto statements. New submitter Mei Nagappan writes with a mellower view, nearly 50 years later: By qualitatively and quantitatively analyzing a statistically valid random sample from almost 2 million C files and 11K+ projects, we find that developers limit themselves to using goto appropriately in most cases, and not in an unrestricted manner like Dijkstra feared, thus suggesting that goto does not appear to be harmful in practice. (Here's the preprint linked from above abstract.)
This discussion has been archived. No new comments can be posted.

Empirical Study On How C Devs Use Goto In Practice Says "Not Harmful"

Comments Filter:
  • by Anonymous Coward on Thursday February 12, 2015 @01:57PM (#49039529)

    It gives me so much more flexibility and power. The computed comfrom is even better.

    • Breakpoints (Score:3, Informative)

      by tepples ( 727027 )

      It turns out that many CPUs have hardware support for comefrom, usually to support debuggers. For instance, x86 has DR0, DR1, DR2, and DR3 [wikipedia.org]. And that's the only place I'd use a comefrom: as a debugging breakpoint.

  • why? (Score:5, Insightful)

    by Anonymous Coward on Thursday February 12, 2015 @01:57PM (#49039531)

    Is that because they were warned by Djikstra that it would be harmful to use it haphazardly? Or is it for some other reason?

    • Re: (Score:3, Insightful)

      Is that because they were warned by Djikstra that it would be harmful to use it haphazardly? Or is it for some other reason?

      1. Because if you use goto in a class assignment, you lose points.
      2. Goto is easy to avoid, and is a symptom of a poorly designed program.
      3. Some compilers don't even try to optimize a function containing a goto.

      I have occasionally used goto as a quick hack, usually to handle error conditions.
      When I later go back and refactor the code, it is always cleaner and more readable without the goto.

      • Re:why? (Score:5, Interesting)

        by Anonymous Coward on Thursday February 12, 2015 @02:30PM (#49039905)

        Really? You loose point for what is really the most sane way to handle cleanup in C? Have the instructors in those courses actually done any real work outside of academia? This is a very common pattern that I've seen in almost every large C code base that I've worked on.

        static int
        do_some_work (context_t context,
                      int x,
                      error_t **error)
        {
            int rv = 0;
            database_t *db;
            data_t v;

            db = get_db (context, error);

            do some work ...

            v = compute_v (context, db, error);
            if (!v)
                goto out;

            more work ...

        out:
            return rv;
        }

        It makes it so much cleaner and easier to read.

        • Re:why? (Score:5, Interesting)

          by Austerity Empowers ( 669817 ) on Thursday February 12, 2015 @02:41PM (#49040051)

          Computer Science and Computer Programming are two different things. The academics are always on a quest for purity, people who work for a living want to get things done as cleanly and quickly as possible. Frequently the two minds align, but you won't convince the academic your goto is pure anymore than he can convince you to rewrite the code to remove it (which you could do).

          • Not all academics are against goto. Knuth is an academic, and he wrote on the structured uses of goto shortly after Dijkstra's edict. (Some of these uses have since been absorbed into constructs like "break" and "continue", but "break" can't break out of more than one loop at a time and "goto" can.)

            • I agree (Score:5, Insightful)

              by NickFortune ( 613926 ) on Thursday February 12, 2015 @04:45PM (#49041511) Homepage Journal

              People forget that Djiksrtra wrote his famous missive back when the dominant languages were PL/1 and Fortran and goto was the main mechanism for flow control.

              Dijkstra's point was perfectly sensible and a valid at the time. I'm just not sure that it deserves to be elevated to the status of Eleventh Commandment.

        • And, the get_db acquired locks and did mallocs, compute_v created a new thread to handle something asynchronously.

          So, bailing out leaves dangling threads, leaking memory, and deadlocks that show up the next time the function is entered.

          It's the easy way out only once.

        • Every "goto out;" can be replaced by a "return rv;" which says explicitly what it does. The dislike of multiple return statements in a function is based on academic thinking, not reality.

          Now, if you were doing more processing after "out:" than just a return statement, there'd be a case for what you're doing. Piling up end-of-function code like that is ugly, but there's often no way to do it better in C. In C++, you'd use RAII for resource management and not need any exit code.

          • The reasoning behind not having multiple return statements is the exact same reasoning behind not using goto, so you're basically solving nothing here.

            Also, the example given is a poor one, it has only one place where an error can be generated (which is not the case you should address with goto, instead, the case where you have lots of steps, each of which could fail is), plus, it doesn't have any real cleanup work to do (e.g. it's entirely reasonable to expect that you may need to deallocate buffers you we

      • Goto is easy to avoid, and is a symptom of a poorly designed program.
        [...]
        I have occasionally used goto as a quick hack, usually to handle error conditions.

        In languages with exceptions, one uses a finally clause (or a C++11 scope guard) to perform cleanup, such as releasing memory or non-memory resources that a function owns. In C, one uses goto to jump to the cleanup code if it detects an exceptional condition. Or is a program that needs to do this sort of cleanup "poorly designed" solely on account of being implemented in C instead of a language with language-level exceptions?

        When I later go back and refactor the code, it is always cleaner and more readable without the goto.

        By "refactor" do you mean "rewrite in C++"? If not, could you give an example of su

      • Because if you use goto in a class assignment, you lose points.

        If the assignment is "Implement a coroutine mechanism for C", why would a sane instructor dock the student for making something like this clear wrapper around goto [greenend.org.uk]?

      • Re:why? (Score:5, Informative)

        by Bengie ( 1121981 ) on Thursday February 12, 2015 @02:40PM (#49040045)
        There may be a better pattern, but in a few cases, I found Goto a lot easier to read than 20 layers of nested If statements. Essentially a situation where you have a pipeline of code doing one stage at a time, but you need it to immediately stop if any one of those stages did not work.

        Not to mention all conditional statements and loops are just a subset of goto. Try writing some ASM.
      • Re:why? (Score:5, Insightful)

        by sjames ( 1099 ) on Thursday February 12, 2015 @02:41PM (#49040063) Homepage Journal

        1 and 3 are certainly true. 2 is not always. For example, if an error condition requires unwinding such as releasing resources. Compared to deeply nested ifs and having to essentially duplicate the entire control flow in the bottom half of the function, gotos can make things much more readable and even improve performance.

        Perhaps a better statement is that goto will be found in code that is either very well designed or very poorly.

    • Re:why? (Score:5, Interesting)

      by firewrought ( 36952 ) on Thursday February 12, 2015 @02:19PM (#49039769)

      Is that because they were warned by Djikstra that it would be harmful to use it haphazardly?

      Programmers are more used to structuring their code (using functions, modules, etc.) and using best practices (minimizing globals, separation of concerns, etc.). This was not so much the case in the late 60's. That, combined with the "goto stigma", means that average developers avoid goto usage and good developers know when it's worth it.

      We saw a similar backlash with the concept of operator overloading. People abused it in C++, the Java designers overreacted and prohibited it, but most languages since then recognize that "yeah, operator overloading's really nice when you're building an API for mathematical constructs" (like complex numbers, quaternions, and matrices). So it's there in C#, Python, D, Rust, Scala, but (from the little I've seen) people seldom abuse it these days.

      • "yeah, operator overloading's really nice when you're building an API for mathematical constructs" (like complex numbers, quaternions, and matrices). So it's there in C#, Python, D, Rust, Scala, but (from the little I've seen) people seldom abuse it these days.

        Why is it there, then? If operator overloading is only useful for mathematical constructions, why not simply bake those things into the language and be done with it rather than provide operator overloading which can, amongst other things, also be used to build those libraries?

        After all, those are libraries. They can easily be provided as part of the language with no impact to the actual language or the language usage... if that is all that overloaded operators are used for! Unfortunately the truth is that o

        • Re:why? (Score:4, Insightful)

          by Chris Mattern ( 191822 ) on Thursday February 12, 2015 @03:20PM (#49040525)

          If operator overloading is only useful for mathematical constructions, why not simply bake those things into the language and be done with it

          Because there are an infinite number of possible mathematical constructions. You can't bake them all into the language; you need to provide facilities for the programmer to write his own.

    • by sjames ( 1099 )

      I think that's likely. It became such a taboo that developers tend to think it over thoroughly before actually using it.

    • by TheCarp ( 96830 )

      I was wondering that too, but, there is another one.... what if the real issue was simply Djikstra's underestimation of how obvious the pitfalls with goto are.

      Its easy to accidentally cut yourself with a knife, its also easy to see the danger and most people learn to use one without cutting themselves pretty quickly. The pitfalls are easy to see, and making mistakes causes pain.... much like Goto.

      The problems with it are easy to see if you just use it a few times. I learned to use goto in applesoft basic,

      • Re:why? (Score:4, Insightful)

        by ClickOnThis ( 137803 ) on Thursday February 12, 2015 @03:35PM (#49040697) Journal

        I was wondering that too, but, there is another one.... what if the real issue was simply Djikstra's underestimation of how obvious the pitfalls with goto are.

        1968 was the year Djikstra wrote his article. At that time, arguably the dominant languages (FORTRAN IV and maybe BASIC) did not have structured control-flow constructs such as if-then-else, do-while and begin-end blocks. Others that contained these constructs (PL-I and Algol come to mind) were struggling for mind-share.

        Without structured control-flow constructs, one is pretty much forced to write goto statements everywhere. I think Djikstra's cautioning against the use of gotos was also a call to abandon them in favor of the structured approaches that the new languages supported. And he was right: if you're using gotos to replace structured control-flow, then you're abusing gotos.

    • by mileshigh ( 963980 ) on Thursday February 12, 2015 @03:52PM (#49040899)

      In the 60's and much of the 70's, most people wrote in high-level languages as if they were coding assembler. Goto's all over the place. Not that they had a choice -- for example, control flow in Fortran IV, the most-used high-level language of the time, featured IF, DO (a crude version of the modern FOR -- not do), GOTO, CALL, RETURN. No else, while, do/while, no modern-style for, case, etc. AND, get this: NO BLOCKS; the IF statement controlled only a *single* statement, so that meant you often *had* to say IF (...) GOTO xxx. Just like assembler. It was awful! There were other less-popular but more-evolved languages, but unstructured practices were very often carried over to those as well. GOTOs were just how most programmers thought.

      That's the backdrop for Djikstra's condemnation of GOTO. Certainly, the then-current mass use of GOTOs was a very bad thing since it completely obscured program logic. If you read the original article, he's not so much condemning GOTO as he's arguing for structured programming.

      Consider GOTO Considered Harmful as a successful wake-up call. By keeping his message black/white, i.e. GOTO is bad, he gave his message punch and made it much talked-about. People started to think in a more structured manner (though at first we thought the "structured crowd" were a bunch of weenies), and started to demand better control-flow features. Pretty soon, structured control-flow was de rigeur in any new or revised language. Fortran even got IF/END IF in Fortran 77!

      People nowadays have hardened the anti-GOTO bias into gospel. At the time, the response was more nuanced, more in line with the spirit of what Djikstra was saying. For example, in 1974 even Niklaus Wirth's new PASCAL (a principled, hard-line structured language if there ever was one) included the goto statement with the warning in the User Manual and Report that "the goto statement should be reserved for unusual or uncommon situations where the natural structure of an algorithm has to be broken." If anybody was going to out-and-out outlaw goto, Wirth would have been the guy.

  • XKCD (Score:4, Funny)

    by rhazz ( 2853871 ) on Thursday February 12, 2015 @02:00PM (#49039567)
    Obligatory: http://xkcd.com/292/ [xkcd.com]
  • by suutar ( 1860506 ) on Thursday February 12, 2015 @02:01PM (#49039577)

    Goto is being used safely (relatively) now, but would have the programming practices that cause that to be true become so prevalent without his warning that it had potential for problems?

    • by Anonymous Coward on Thursday February 12, 2015 @02:20PM (#49039779)

      As someone who saw the programming practices of the 1960s and early 1970s, I can assure you that Dijkstra's warning was needed.
      It caused a massive change in practices among software professionals, within a few years GOTO had almost disappeared from most new code.
      I remember seeing code from a "sales engineer" in 1975 that was so full of buggy gotos that we refused to even attempt to debug it.
      He learned.

    • Yes, because people would have run into those problems and someone else would have made the same warnings.

      He probably saved someone a lot of grief way back when, though.

  • There is an implication that Dijkstra was wrong about the goto - the implication being based on how conservatively it is used.

    Perhaps it is wiser to conclude that the goto is used so conservatively because Dijkstra was right and that programmers have, in general, taken his wisdom to heart and avoided the goto except for those instances where, properly documented, it is the best tool for the job.

    (By prophylactic prediction I mean the sort of warning or planning that completely forestalls the danger predicted, through awareness, preparation, etc. Kind of like the Y2K non-event.)

    • I agree, but i can only think of one instance that gotos are appropriate and that is cleanup. I think this is basically because C does not have any nice way to handle cleanup, a finally block would get rid of most valid uses of goto.

      • I agree, but i can only think of one instance that gotos are appropriate and that is cleanup. I think this is basically because C does not have any nice way to handle cleanup, a finally block would get rid of most valid uses of goto.

        Problem is, a finally block effectively changes the meaning of code within it by tagging any return statements with extra code. A line being changed by another line far away seems far more inelegant and prone to confusion than goto.

    • by dbc ( 135354 )

      Indeed. And if one is old enough to have read/maintained any FORTRAN code dating from Dijkstra's era, you can understand why he wrote this paper. A lesser being would have gone off on an apoplectic rant. In fact, I may be one of those lesser beings, myself.

    • It reminds me of a joke. It was something like :
      * What do you do for a living?
      * I protect the population : I'm a velociraptor hunter
      * But, there's no velociraptor!
      * You're welcome.

  • goto fail (Score:5, Informative)

    by Anonymous Coward on Thursday February 12, 2015 @02:02PM (#49039599)

    https://www.imperialviolet.org/2014/02/22/applebug.html

  • Well, yeah (Score:4, Informative)

    by Anonymous Coward on Thursday February 12, 2015 @02:03PM (#49039601)

    Because we all got the warning, and thus did not write horrible goto-festooned spaghetti code and only use goto when appropriate. This means Dijkstra's letter was a success. Also, it was Niklaus Wirth who decided to use the "considered harmful" verbiage, not Dijkstra.

    • by HBI ( 604924 )

      Agreed. One must think back to the BASIC, PL/I or Fortran-dominated 70s to understand why Djikstra might have been worried. The problem was solved in practice.

    • by narcc ( 412956 )

      Now, we write horrible, impossible-to-follow, spaghetti code without goto!

      Remember kids, 'spaghetti code' refers to code with complex *control flow*. That is, if you trace it with a pencil, you end up with a document that looks like a plate of spaghetti. We're, arguably, worse-off now than we were before goto became taboo.

      We learned the wrong lesson.

      In smalltalk, everything happens somewhere else. --Adele Goldberg

  • by Anonymous Coward

    All languages can be abused.

    goto is no different than if nests or giant nested for loops or any other maddening crap people can come up with. If you look at the code most C compilers come up with they are not afraid of a goto...

    Goto used correctly is a good tool. Its just a tool. Do not treat it as something bad or good. Look to how it is used.

    • by narcc ( 412956 )

      If you look at the code most C compilers come up with they are not afraid of a goto

      As if they had a choice!

  • by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Thursday February 12, 2015 @02:05PM (#49039623) Homepage

    This makes sense for a couple reasons.

    First, abusing goto really serves noone. It doesn't make code quicker to write. It certainly doesn't make it easier to understand. There is no benefit to it.

    Second, I'd argue that very few people want to write new code in C these days. Those who do have specific reasons for it and are probably a bit more experienced or passionate and thus aren't the kinds of people who'd readily abuse things. The ones who would are going to be mostly attracted to easier high-level languages that don't allow the abuse in the first place.

    • Goto these days is a stenography tool... it's designed to make the code harder to read.

    • by DamonHD ( 794830 )

      Lots of 'Internet of Things' code will be written in C (with some ASM and C++) as the 'things' tend to be resource constrained. That's a big market coming up.

      I'm enjoying using C again on devices with similar performance to those I was using 30 years ago (now: ATMega328P running with 1MHz CPU, ie 1 MIPS; then Z80A with 4MHz clock making for ~1MIPS) but with lots better development tools this time, and several GHz of laptop to run them on.

      https://sourceforge.net/p/open... [sourceforge.net]

      When not writing C (and developing h

      • by itzly ( 3699663 )

        Lots of Internet of Things stuff runs on ARM Cortex M3/M4 on > 100 MHz CPUs. Plenty of resources for lazy development.

  • by Shakrai ( 717556 ) on Thursday February 12, 2015 @02:06PM (#49039627) Journal

    I'm not a "hard core" coder (defined here as someone who does nothing but development) but I've been writing C for 15+ years (it was the first language I learned and remains my favorite) and have yet to encounter a situation where the use of 'goto' is a requirement or even better than the alternative. The one circumstance where I've seen it advocated is for the main loop of a long running program but I'm not certain why goto is any better than while (1) (or similar constructs) in this scenario. Correct me if I'm wrong but the main argument against goto is that it results in haphazard code that's hard to follow. I think this is true, even in the simple case of using goto to replace while (1), never mind the more convoluted examples that invariably result when goto enters the equation.

    So, people who are smarter than me, what am I overlooking? What C coding scenario presents itself where goto is the most eloquent solution?

    • by vadim_t ( 324782 )

      Error handling with multiple instances of allocation.

      Eg, something like:

      char *buf1 = malloc(...);
      if (!buf1) goto abort1;

      char *buf2 = malloc(...);
      if (!buf1) goto abort2;

      char *buf3 = malloc(...);
      if (!buf1) goto abort3;

      return;

      abort3:
      free(buf2);
      abort2:
      free(buf1);
      abort1:
      return;

      Also, bailing out of multiple nested loops.

      • by vadim_t ( 324782 )

        ...and of course I messed up, that should be:

        if (!buf2) goto abort2;
        if (!buf3) goto abort3;

        The ability to edit comments would be nice.

  • by davidwr ( 791652 ) on Thursday February 12, 2015 @02:10PM (#49039665) Homepage Journal

    I bet the "valid random sample" didn't include any projects from the Obfuscated C Code Contest [ioccc.org].

  • That result's because programmers got the ideas in "Goto Considered Harmful" pounded through their skulls while they were learning, and handled it like they would dynamite: it's very effective and the best tool for certain jobs, but it's also very dangerous and capable of causing a ton of damage so you should handle it with an abundance of caution. tl;dr: "Use it to crack huge boulders and tree-stumps, not to loosen bolts."

  • "GOTO" existed before subroutines and functions were added, and it was back in the days of line numbers. This was the point where the main menu part of a program had to jump over to the appropriate part of the program, now we just call the appropriate routine.

    • "GOTO" existed before subroutines and functions were added, and it was back in the days of line numbers. This was the point where the main menu part of a program had to jump over to the appropriate part of the program, now we just call the appropriate routine.

      But more than that, GOTO is how processors work at the lowest level. All of those fancy blocks in a modern language get turned into "jumps" and such at the lowest levels when compiled. The first computer languages - such as fortran - were a pretty thin veneer over assembly, anyway, so gotos made sense.

  • by Chess_the_cat ( 653159 ) on Thursday February 12, 2015 @02:18PM (#49039761) Homepage
    Headline should read "Thanks to Dijkstra's warning, GOTO in practice not harmful."
    • by DamonHD ( 794830 )

      Bingo: you win tonight's Internets...

      Rgds

      Damon

      PS. Like all that Y2K work I wasn't doing in a bank that wasn't necessary except that it was...

    • So true, but out of mod points :D
      And yes... I read at -1 too :)

  • Goto messes with readability and long term maintenance. Anyone who uses Goto is probably going to use it correctly. Otherwise you wouldn't use it. But you use it to construct loops, and functions which is unnecessary and illegible compared to every other option.
  • by Marginal Coward ( 3557951 ) on Thursday February 12, 2015 @02:24PM (#49039823)

    It's no surprise that goto's are used sparingly - and generally only with very good reason - by modern programmers. Dijkstra's paper is dated 1968, which is about the time ALGOL was invented. ALGOL which was the first block-oriented language. Heck, maybe its design was even influenced by Dijkstra's paper - who knows?

    Given a language that supports blocks (and all modern languages do), there's little reason to use gotos. Instead, you use blocks and related goto-like constructs such as break, return, try/catch, etc. Anything but a literal goto.

    IIRC, the CPython source code has a few goto's in it. I remember that Tim Peters once defended that as being the best solution (in C, at least) for certain very exceptional situations. It's no coincidence that they're used very, very sparingly there. And maybe they wouldn't be needed at all in CPython if C had a try/catch construct - like Python itself.

    In my own case, I've used them mostly when transliterating some ancient FORTRAN code into C. Rather than untangling the code into blocks, it was simply easier to replicate the goto's. At the time, I actually had to consult K&R to brush up on C's goto syntax. Also, the FORTRAN code I was working with was proven and needed little maintenance, so removing the goto's was more likely to make it worse than to make it better.

  • If you check present day code you won't see much use of GOTO. That is because the programmers have found an even more nefarious and orders of magnitude worse construct, COMEFROM statement.

    Really this is a COMEFROM statement, no?

    bool OnRightButtonClickCallBack(void *a, void *b, void *c){

    int xx=int(a);

    int yy=int(b);

    global_window *gw=(global_window *) c;

    ...

    ...

    }

  • longjmp() (Score:5, Funny)

    by stox ( 131684 ) on Thursday February 12, 2015 @02:51PM (#49040167) Homepage

    is far more entertaining than a mere goto.

Time is nature's way of making sure that everything doesn't happen at once. Space is nature's way of making sure that everything doesn't happen to you.

Working...