• 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)
    Comment held for moderation.

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