Thread

1. JoshTriplett · 1789746575 · 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 · 1789751761 · 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 · 1789751975 · 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 · 1789753707 · 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 · 1789754322 · 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 · 1789778161 · focus · HN ↗

                  The original UB was to allow the compiler to merge two loops without proving termination.

                  1. CamperBob2 · 1789793057 · 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 · 1789801520 · 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. mitxela · 1789822776 · focus · HN ↗

                           You might ask why it's important that the first loop terminates since in this case the extra side effect would just be a dead store - but if the first loop doesn't terminate then it's possible B is an invalid pointer and then accessing it during the first loop is UB when it shouldn't be. Making a nonterminating loop UB is the patch for this.

                           The standard example is a linked list instead of an array because the compiler can't prove it never has a cycle.

                           1. imtringued · 1789890729 · focus · HN ↗

                              So you're saying the person you are responding completely failed to make their point clear?

                              Why use a for loop with a bound as an example instead of while loops with linked lists? He or she can prompt an LLM for a better example so laziness doesn't count as an excuse.

                              1. teo_zero · 1789912064 · focus · HN ↗

                                 > Why use a for loop with a bound as an example instead of while loops with linked lists?

                                 I'm the author of the example. I wanted to keep it as simple as possible, and this is the most common form of for loop. I was sure that HN readers would be clever enough to "map" it to whatever they have in their mind that satisfy the undecidability of the condition.

                                 But since you're nitpicking, I haven't specified the types of i and n: i is uint8_t and n is uint32_t. Does it terminate? It depends on the value of n!

Unofficial Hacker News client; not affiliated with Y Combinator.