• Mark (unregistered)

    Not only have they forgotten while exists, they've forgotten how for loops work in C.

  • (nodebb)

    I don't think the author of that code snippet ever knew about the while loop.

  • Little Bobby Tables (unregistered) 
     1000 CONTINUE
C        DO SOME STUFF
          :
          :
          IF (EXLOOP .NE. .TRUE.) GOTO 1000
  • Ebbe K (unregistered) in reply to tahir_ahmadov

    The author didn't even know a lot about for-loops. To create a loop that does not terminate yuo just write:

    for(;;)

    Much quicker than

    while(1)

  • not a robot (unregistered)

    for (;;) { Console.WriteLine("Frist!");}

  • Chronomium (unregistered)

    I think we need a new language construct.

    for (ever) { [...] }

  • Adam P. Goucher (unregistered)

    You don't need a new language construct; you can just #define ever ;;

  • P (unregistered)

    TRWTF is the code being shown is wrong because a colon is in place instead of the second semicolon. FTFY:

    for (int i = 0; i < int.MaxValue; i++)

  • P (unregistered)

    Another TRWTF is < is used as <= so it's not actually a infinite loop. Candidate for an URGENT issue.

  • scragar (unregistered) in reply to Chronomium 
         #define forever for(;;)

     forever {
           // ...
     }

    Pretty much how I've always done it. Given there's a tendency to define ever to ;; or (;;) using forever as one word not only reads better but has less chance of causing problems.

  • my name is missing (unregistered)

    I always preferred the untilHellFreezesOver { } construct

  • Rick Townsend (google)

    Maybe it's supposed to be a speed up loop?

    https://thedailywtf.com/articles/The-Speedup-Loop

  • Geoff (unregistered)

    I used to work with an embedded scripting language with a C link syntax. it let you script out a lot of operation in an ERP tool. Because of the way it evaluated tokens and expressions, there were lots of quirks.

    For example:

    While(true){ do stuff... }

    ran slower than

    while ( 1 < 2 ){ do stuff...}

    which ran slower than

    for ( i = 0; i < 2147483648; i++) { do stuff... } // i will overflow and never hit 2,147,483,648 as result the loop runs until a break statement in the loop

    Now that last one we used rarely because it was "to clever" and there was a real fear a future update or something could break our code; however for some operation like serial I/O where buffers could fill (it was possible to call into system C libraries) it made things work more dependably.

  • (nodebb) in reply to my name is missing

    https://esolangs.org/wiki/~ATH

  • capt bullshot (unregistered)

    That loop might be on purpose. I've seen such code used as a crude timeout in embedded devices to prevent the code from stalling if e.g. an I/O register doesn't give the expected result, maybe because the initialization of some HW failed. If you don't have setup your infrastructure yet, you don't have access to timers etc. to manage the timeout in a more stylish fashion.

    Clearly not appropriate style for SW that is intended to run on a server or desktop.

  • ZZartin (unregistered)

    Well without knowing what was commented out I can't say whether this makes sense or not. It's entirely possibly there was some operation that needed to be performed i times or until it returned some kind of value.

  • Mischa (unregistered)

    Or maybe it is used for debugging purposes since it yields the iteration number.

  • Kashim (unregistered)

    Interesting point: no one is noting that there is a big difference between something that runs forever, and something that runs 2.1 billion times.

    This could just be a very, VERY poor way of giving the loop a timeout.

    for(;;) will hang a program if it never breaks.

    for(int i; i < 2100000000; i++) will end, even if after a really long time. Not even that long if it is a fast loop. Not defending that kind of behavior, but I've seen students do things this way when they didn't know better.

  • Giulio (unregistered)

    Provided that's a quite obscure way of doing it, this may be a way of limiting the execution of a loop that may technically run forever (as it's the case for iterative approximation algorithms, that are assumed to converge at some point, but may not do so due to a bug somewhere). Ideally, one could do something like that, and then spit out a log message, if the loop exited because it had been running for too long, so that debuggers can know the program is running on a potentially inaccurate result. But this world is far from ideal, so...

  • Ex-lurker (unregistered)

    I'm kinda rusty in my C-fu, but is the compiler supposed to accept a comma and a statement in the conditional part of the for?

    BTW, while this is really not the right way that these things should be handled, if all the author wanted was a forever loop he could just not include the i++ in the for. He or she fails basic programming for(ever){} .

  • Kaewberg (unregistered) in reply to Kashim

    for(int i; i < 2100000000; i++) will end, even if after a really long time.

    Better test it before saying that. :-) 2 ms, in Java.

  • Brian Boorman (google) in reply to Kaewberg

    BS. If that was the statement you executed, then the compiler short-circuited the logic and never incremented I 2,100,000,000 times. Even the most compact assembly language would take a few seconds to execute that loop.

  • (nodebb)

    I once had to loop a block of code. There was no guarantee it would hit the break test. The index was never referenced. It left me searching for the longest time.

  • PHPLite (unregistered)

    People said it couldn't be done... but we're always proven wrong, this is an O(1) collection searching algorithm, that's even more efficient than a B-Tree /s

  • (nodebb)

    Well, the problem with that is a half decent optimizing compiler will notice that i isn't used anywhere in the loop, hoist all that stuff out and throw the loop away.

    So unless you compile with all optimisation switched off (sadly I work at a place that indulges in that habit), that won't cripple the performance as much as it deserves to be crippled.

  • linepro (unregistered)

    int.MaxValue might be 32767 if this is for a 16 bit machine.....

  • Wizofaus (unregistered) in reply to ZZartin

    That was exactly my thought. If the code had actually included some distilled version of what was being done in the loop we could at least judge if this were a true WTF.

  • Wizofaus (unregistered)

    TRWTF is the comma before ++I. The question is what happens when i hits MAX_INT and gets incremented. I guess it rolls over to MIN_INT so it does indeed loop forever. But on some platforms it may well throw an exception, which might be useful in stopping it running indefinitely...I guess...

  • (nodebb)

    I see the problem. Yes, it is very wasteful. Why not just:

    for (;;)
{
    // body of the loop, does not depend on i
    if ( /* some condition, does not depend on i */)
        break;
}
  • (nodebb) in reply to thosrtanner

    Well, the problem with that is a half decent optimizing compiler will notice that i isn't used anywhere in the loop, hoist all that stuff out and throw the loop away.

    That depends on the elided contents. If the operation inside is doing something that can't be hoisted (such as reading from volatile memory) then the compiler will do as it was told to.

  • Wizard (unregistered)

    The decision on for vs while is easy and shouldn't need debating.

    If you know how many times you're looping it's a "for", if you don't know its a "while". Using "break" is effectively a "goto". Avoid it

  • Wizard (unregistered)

    I think the "for (ever) { [...] }" is far more readable than "forever {}" or "untilHellFreezesOver {}".

    The first one clearly shows that it's going to be looping. The second two could easily be taken to be some sort of "anonymousy" type of method which would only run the once if it were ever called. Just looking at the different way you could pretty well be damn sure how "ever" is implemented without having to go to the code. The other two..? .... I bet most dev's would be hitting the go to implementation to make sure?

  • dpm (unregistered)

    Seriously? No one is going to mention do { stuff; } while (condition); ?

  • (nodebb)

    AFAIK,

    for (init; test; incr) { body; }

    is equivalent to (and actually compiled exactly like)

    init; while (test) { body; incr; }

    (unless test is empty - then it is replaced by true, obviously.)

  • Wizard (unregistered)

    @dpm - well the "do/while" construct is only really useful if you know you need do something at least once.

  • Wizard (unregistered)

    @dpm - well the "do/while" construct is only really useful if you know you need do something at least once.

  • (nodebb) in reply to P

    That's no good, you'll get "comparison is always true due to limited range of data type" warnings/errors if you do that.

  • Alex Ford (github)

    I thought that for i in range(0,n) wad a fairly standard construct in Python for doing something n times even if you didn't necessarily need the loop counter. I don't think I'd ever do that with n=sys.maxsize, but for a 3x or 10x retry loop, I think that's a lot more readable than setting up a timer.

Leave a comment on “For a Long While”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article