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. saghm · 1789750371 · focus · HN ↗

      I guess given that it was UB before, the compiler was already allowed to put a system call here if it wanted for some reason

      1. fc417fc802 · 1789767883 · focus · HN ↗

         Yes, it was a horrible situation that has been replaced by an only slightly less horrible situation.

         1. saghm · 1789768857 · focus · HN ↗

            I don't totally agree with this. To me, UB is an order of magnitude worse than pretty much anything else, so this is more than "slightly less" horrible. I don't necessarily disagree that this is still horrible, but I also don't write an C++, so I'm mostly just commenting as an outside observer.
      2. chowells · 1789784252 · focus · HN ↗

         Not only that, the code was wrong. The specification is quite clear that correct programs don't cause UB to be executed at run time. If your wrong code now produces wrong results, that's because it's wrong. That your compiler allowed you to get away with it for decades is a compiler bug, not a feature.

         Do I fully believe all of the above? Not exactly. But compiler authors do. Does it make a really good argument to never use C or C++? Yes. If only we had 50 years of optimization work in any language with better semantics.

         1. saghm · 1789792710 · focus · HN ↗

            Yeah, my slightly more verbose take is that a language that requires you to not ever make any mistakes in order to have a program behave in a predictable way is not a particularly good choice of language if you the ability to pick something else.
         2. JoshTriplett · 1789804000 · focus · HN ↗

            The mistake was declaring infinite loops to be UB in the first place.
         3. throwaway786678 · 1789808124 · focus · HN ↗

            > That your compiler allowed you to get away with it for decades is a compiler bug

            That UB was added in C++11.

            1. chowells · 1789813680 · focus · HN ↗

               That sounds like 1.5 decades to me...
         4. TuxSH · 1789824332 · focus · HN ↗

            FWIW while(true) / for(;;) (or any other loop condition that is a true constant-expression) is NOT UB in C, only C++.

            In any case stuff like __asm__ __volatile__("" ::: "memory") prevent such optimizations in the rare case you do need branch-to-self.

         5. classified · 1789826392 · focus · HN ↗

            > don't cause UB to be executed at run time.

            The insidious thing about UB is that it doesn't necessarily have to be executed to wreck your program. UB is not primarily about runtime behavior, it's about how the compiler interprets your code. The behavior that is undefined is your compiler's behavior.

            1. chowells · 1789845228 · focus · HN ↗

               You're right. I didn't enumerate every way UB can make a program go wrong. I'm sure I don't even know every way that can happen. But "UB doesn't happen at run time" is an assumption that lots of "optimizations" are based on.
      3. cryptonector · 1789793593 · focus · HN ↗

         Yes, but now it has to. I guess that's better? than UB, maybe.

         1. saghm · 1789862493 · focus · HN ↗

            Oh, definitely agreed. It's still not great, but it's a lot better than before.

Unofficial Hacker News client; not affiliated with Y Combinator.