‹ BackHN Continuity

Thread

C++26: Trivial infinite loops are no longer undefined behaviour

173 points · 290 comments · ibobev

  1. JoshTriplett · · focus · HN ↗
    > When both conditions are met, the loop body is replaced with a call to std::this_thread::yield().

    Insert screaming here.

    An infinite loop, with no library calls whatsoever, gets a system call inserted. That's a horrible surprise waiting to happen.

    The entire concept of the "forward progress guarantee" is broken. An infinite loop should compile to an infinite loop. Nothing more, nothing less.

    1. marcosdumay · · focus · HN ↗
      I don't understand your problem. Did you expect your C++ program to get uninterrupted access to the computer? What progression do you think isn't happening there?

      I think you are misinterpreting that. That phrase unambiguously says the loop is preserved on the final binary.

      1. JoshTriplett · · focus · HN ↗
        I expect an infinite loop to be compiled into, for instance, a jump instruction jumping to itself. The OS, if there is any, is welcome to interrupt and context switch. I don't expect code that has no function calls at all to have a system call inserted into it.
        1. marcosdumay · · focus · HN ↗
          Ok, I get this.

          The problem is that what you want is completely against the spirit of the entire language.

          If your point is that C++ should be more like C in general, I can agree with that. But if your point is that C++ should be literal on this specific case, performance be damned, and the rest of it is ok, then no, that's a bad one.

          1. JoshTriplett · · focus · HN ↗
            I was utterly unconvinced that the original infinite-loop UB gave the compiler any important performance optimization, and I'm unconvinced that this is providing useful value to compensate for its surprise. If I wanted a yield in my infinite loop, I'd add one.
            1. mitxela · · focus · HN ↗
              The original UB was to allow the compiler to merge two loops without proving termination.
              1. CamperBob2 · · focus · HN ↗
                What difference does it make? If the loop doesn't terminate, it doesn't terminate, which is almost always a bug, except when it's not. If it does terminate, then great, it terminates.

                Merging a buggy loop with another loop creates... a buggy loop.

                1. teo_zero · · focus · HN ↗
                  Take this example:

                    for (i=0;i<n;i++)
    A[i]=0;
  for (i=0;i<n;i++)
    B[i]=0;
                  It can be conveniently transformed into this:

                    for (i=0;i<n;i++)
    A[i]=B[i]=0;
                  They are exactly equivalent except if the first loop never terminates.

                  Now, the compiler could try to understand if the first loop does or doesn't terminate, and apply or not the optimization accordingly, but Turing tought us that is indeed a hard task!

                  Or it could decide to never apply it, for fear of those rare and usually pathological cases where the first loop doesn't terminate.

                  Or it could decide to apply it by default and accept that in those cases the program does something different than what the source code says. The latter is better known as UB.

                  The third option won, and that's why infinite loops are UB in the standard.

                  1. imtringued · · focus · HN ↗
                    Your explanation is completely insane.

                    > but Turing tought us that is indeed a hard task!

                    Analyzing whether a bounded loop terminates is impossible, got it.

                    >Or it could decide to apply it by default and accept that in those cases the program does something different than what the source code says. The latter is better known as UB.

                    But the reason why it lets the compiler fuse the loops has nothing to do with whether the loop terminates or not. The infinite loop UB is just a way of adding more UB and then invoking non infinite loop optimization.

                    We don't know if A[i] aliases with the pointer that stores the address of the B array and note I mean B itself not A and B overlapping. It could also alias with the loop bound. So the first loop must run until completion simply because it could accidentally overwrite a pointer or variable that is used in the second loop.

                    But now that we have infinite loop UB we can ignore all of that and it's not because infinite loops themselves produce optimization potential, it's because more stuff is UB now so the compiler is allowed to break aliasing rules, which is the actual thing that was preventing the optimization. The infinite loop UB is just the permission slip.

                    1. teo_zero · · focus · HN ↗
                      Whenever you write a succinct example or a metaphor to try to explain in a few words a complicated concept, someone will nitpick small details of your construction, thus focusing on the form and missing the spirit!

                      Forget if "i<n" is decidable or not: the sense is that there will always be some loops that the compiler can't determine if it's finite or not.

                      Forget if A and B can alias or not: the sense is having two independent actions that can be executed in the same loop or in two consecutive loops.

                      Let's see... what about the following example, that replaces all a's with @ and all e's with & in a zero-terminated string s?

                        for (char *p=s; *p; p++)
    if (*p=='a')
      *p='@';
  for (char *p=s; *p; p++)
    if (*p=='e')
      *p='&';
                      If a compiler is allowed to assume that the first loop terminates, then it may optimize it to:

                        for (char *p=s; *p; p++) {
    if (*p=='a')
      *p='@';
    if (*p=='e')
      *p='&';
  }
                      Is this explanation less insane?
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.