• Jonas (unregistered)

    Do we know for certain that continue; would work? It could be that the condition evaluates to false prematurely and exists the loop.

    Goto is great in languages without built-in structured error handling, such as C, and not a mirage.

  • (nodebb)

    Everybody knows that you should never use "goto" statements

    Like most things that "everybody knows", this isn't, as written, true, because it's an overgeneralisation.

    Well, except in one or two rare circumstances that you won't come across anyway

    And this qualification is also not true. goto permits an optimisation of a particular structure of code where you want to allocate a bunch of things and fail if any of the allocations fail, and clean up the mess afterwards. Simply set up the variables that receive the results of the allocations (pointers that you assign the return of malloc() to, etc.) pre-initialised to NULL or whatever value is useful, and then if anything fails, you goto the cleanup phase at the end, which calls the appropriate deallocator function to release everything. Just make sure that the deallocators are NULL-safe(1).

    (1) Deallocators that aren't NULL-safe (C free(p) and C++ delete are NULL-safe by definition, except if some idiot wrote a custom operator delete that isn't) should be protected from NULLs at the point of call, and I also recommend chastising the idiot that wrote it. GAU-8 optional.

  • FTB (unregistered) in reply to Steve_The_Cynic

    " goto permits an optimisation of a particular structure of code where you want to allocate a bunch of things and fail if any of the allocations fail, and clean up the mess afterwards. "

    @steve ... maybe try using a language that has RAII, stack unwinding and exceptions. The compiler writes all those gotos and mess-cleaning code ... and it doesn't have bad hair days.

  • David-T (unregistered)

    The goto cont does not have the same effect as continue would.

    Continue would jump to the end of the loop body, re-evaluate the condition and start another iteration only if the condition is true.

    goto cont will unconditionally jump to the beginning of the current iteration, without re-evaluating the condition.

  • (nodebb)

    For those lacking the proper C/C++ context:

    https://en.cppreference.com/w/cpp/language/continue.html

    Addendum 2025-06-25 08:40: Causes the remaining portion of the enclosing for, range-for, while or do-while loop body to be skipped.

    Used when it is otherwise awkward to ignore the remaining portion of the loop using conditional statements.

  • (nodebb)

    continue really isn't much better than goto. I don't think I've ever come across a case where you couldn't structure your code more logically and obviate it. For example, both goto cont statements in today's WTF could be removed easily by understanding that an if statement can have an else clause.

  • (nodebb) in reply to Steve_The_Cynic

    Yeah, I agree, there's nothing bad about goto, every execution branch only exists because of one, it's a fundamental operation of the Turning Machine. The problem is more the people using goto the wrong way which align with the people not doing proper memory management or null checks or immutability checks or http message validation or simply put sloppy developers. It doesn't matter how much rules, guide lines, technically barriers or analyzers you throw at them, in the end a sloppy developer will still be a bad developer and nothing will be able to prevent this. They are the human equivalent to the halting problem :-)

  • (nodebb)

    Why wouldn't you use:

    while (sysmgr->getProcessCount() != 0 )
{
    while (! sysmgr->CurrentProcess()->IsActive() )
    {
        sysmgr->CurrentProcess()->TryInactivate();
        Sleep(DEFAULT_TIMEOUT);
    }
}

    It could take 3 calls or 2 calls or 7 calls, but doesn't use goto

    Addendum 2025-06-25 10:22: EDIT: Both loops would be "infinite" until the process is inactivated. If I have a defect in my logic, can somebody please explain it to me.

  • (nodebb) in reply to FTB

    @steve ... maybe try using a language that has RAII, stack unwinding and exceptions. The compiler writes all those gotos and mess-cleaning code ... and it doesn't have bad hair days.

    I'd love to, but sometimes you're stuck with modifications of large bodies of C code that can't be trivially replaced with(1) C++(2).

    (1) translation: "rewritten from the ground up using"

    (2) You mentioned RAII, therefore for practical purposes we're talking about C++.

  • (nodebb) in reply to Steve_The_Cynic

    Deallocators that aren't NULL-safe

    fclose comes to mind.

  • Jimbob (unregistered)

    I'm glad the author clarified that this is a case where it's OK to use goto; I might have been worried otherwise.

  • Dan Swartzendruber (unregistered)

    Old (V6) AT&T Unix had a process scheduling routine called 'swtch' :)

  • (nodebb)

    GOTO being bad is only in the sense of BASIC where it was one of the few control statements that changed the code flow. It's considered bad because it lets you jump to arbitrary places in the code. This creates awful levels of spaghetti code that can tie itself in knots because you can jump anywhere in the code.

    In most other languages, even in C, there are limitations on where a GOTO will actually land - like C the GOTO must be within the same function. You cannot jump to a label in another function - the target must exist within the function itself. Thus they retain their usefulness as a way to unwind complex initialization steps without having extreme nesting of conditionals. Thus, they're often used when doing initializers which require setting up a bunch of things which may fail.

  • (nodebb)

    As noted above, 'goto cont' won't do the same as 'continue' - it will skip the loop check entirely (though if this had been perl, he could have used 'redo' and avoided this mess. perl is a wonderful language!)

    I vaguely feel given the names in that code, you don't actually want to keep testing the conditional- - at least without a good hard look at the way the processes are allocated and possibly reused.

  • (nodebb) in reply to Bananafish

    It would have an extra sleep in it if tryinactivate succeeded the first time. This might or might not be a problem (and given that code i'd imagine might is more likely than not!)

  • Loren Pechtel (unregistered)

    GOTO has slowly been replaced with a variety of more specialized flow controls.

    Between try..finally and early returns I haven't seen a use case for it in many, many years.

  • Officer Johnny Holzkopf (unregistered)

    One of the best cases to use GOTO is: "GOTO pub; INPUT booze" - it will help forget all the trouble one careless "goto fail;" brought upon us...

  • Tim R (unregistered)

    in cases like this where there is any complexity or subtlety at all around loop termination conditions, I usually prefer an infinite loop and use break or return statements to explicitly exit. it's generally much easer to read.

  • (nodebb) in reply to thosrtanner

    It would have an extra sleep in it if tryinactivate succeeded the first time. This might or might not be a problem (and given that code i'd imagine might is more likely than not!)

    Thanks for your reply. If you mean my solution would introduce a sleep, I don't think so. If you're saying it might introduce a problem that doesn't already exist, I can't defend that. We don't know what "/* ED: Snip */" contains (might be a good thing). Creating a loop for 3 iterations would force a 3×DEFAULT_TIMEOUT lag regardless of activation state, but I don't think what I wrote is worse than what was submitted. If the current process is inactive it should skip the loop entirely, but it should loop infinitely (as the original code does) while the process is active. At least, that was my intention.

    [Disclaimer: Computers do what you tell them to do, not what you think you're telling them to do!}

  • LZ79LRU (unregistered)

    Honestly, I sorely miss GOTO in modern languages. Being able to jump to any arbitrary line of code anywhere in the codebase at will allows for unprecedented amounts of DRY that you just can't get any other way. Forget DRY at the function level. We are talking about it at the line of code level. As in, you literally newer have to write a line of code twice.

    The closest thing you can get to that now a days is to have each line of code be its own function and than put all those as static in a single static global file. But that's far too verbose to be practical.

  • John Ramsden (unregistered)

    They say squirrels are rats with good PR, and likewise arguably "continue" statements are "goto"s with good PR!

Leave a comment on “Classic WTF: When it's OK to GOTO”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article