‹ 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. ozgrakkurt · · focus · HN ↗
      But the compilers have to optimize the crap code in big tech codebases by 0.5%, it saves a lot of money.

      Also performance doesn't matter that much and developer time is more important btw, keep using react.

      1. muvlon · · focus · HN ↗
        It's not even about optimizing some big tech codebase by 0.5%. The progress guarantees in particular are in place s.t. Nvidia can choose a certain implementation strategy in Cuda C++ that has "surprising" consequences for users (one thread getting stuck in an infinite loop that never yields can livelock its entire warp) but still get to claim "full C++ standards compliance".
        1. JoshTriplett · · focus · HN ↗
          So let it livelock the entire warp when someone writes an infinite loop. Should we start replacing integer division by zero with INT_MAX so that people aren't "surprised" by their program crashing?
          1. muvlon · · focus · HN ↗
            I mean that's what they did, and that's why there's that UB. All I'm saying is that this is the "weird platform behaviors exist and must be legalized by the standard" kind of UB and not the "we want a 0.5% win for benchmaxxing" kind of UB (the standard has plenty of both).
            1. fc417fc802 · · focus · HN ↗
              No, they didn't. UB is a cop out and inserting yield is just plain bad. Locking up one or more threads in an implementation defined manner would be the outcome of least surprise (I already know it's going to lock up at least the one thread).
              1. mitxela · · focus · HN ↗
                The standards intended interpretation of UB was always intended to be something like "implementation defined, no documentation required" to allow for implementation weirdness, even unpredictable ones. It was compiler authors who decided do abuse this allowance to do really unintuitive things instead of weird platform weirdness.
                1. IcyWindows · · focus · HN ↗
                  100% There are implementations that have sane behavior for "UB" instead of making it an excuse to misbehave.

                  The ISO standard is not the same as a language from a single vendor.

                  1. mitxela · · focus · HN ↗
                    IIRC a lot of it was benchmark gaming between GCC and LLVM.
              2. cryptonector · · focus · HN ↗
                Because one can bleeping see that that's what would happen. Locking up a thread isn't a good thing, but it's a lot better than UB. There was never a need to make this UB.
        2. mitxela · · focus · HN ↗
          Isn't that the strategy for most of the stuff in C++? It's the common denominator of a wide variety of platforms. That's why numbers didn't have to be two's complement and characters didn't have to be ASCII for ages.
        3. mschuetz · · focus · HN ↗
          I don't see the issue. Just let wrong code do wrong things But let it do the expected wrong thing, rather than changing the code to something unexpected.
          1. cryptonector · · focus · HN ↗
            "No." <-- the C++ committee.
          2. Dylan16807 · · focus · HN ↗
            Good luck defining "expected" for most of the more complex cases.
            1. mschuetz · · focus · HN ↗
              Seems trivial to me for infinite loops. Nothing special to specify here, they're already specced by the definition of loops.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.