‹ 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. ibobev · · focus · HN ↗
      > An infinite loop should compile to an infinite loop.

      I think that a compiler option should control this. It can be a nice optimization, but the programmer should be able to opt out.

      1. Xirdus · · focus · HN ↗
        The programmer can opt out by terminating the loop.
      2. WalterBright · · focus · HN ↗
        Every flag that changes the semantics of the code bifurcates the language into two languages.
        1. ibobev · · focus · HN ↗
          If we accept this definition, C++ already seems to be many different languages. At my job, I'm currently fighting floating-point determinism issues across different build configurations, compilers, CPUs, operating systems, and standard library and libm implementations so that snapshot tests pass with the same hashes on all platforms. I can confirm that this is a complete nightmare.
          1. WalterBright · · focus · HN ↗
            Yup. I tried hard to not allow D's behaviors to be changed based on a compiler switch. Yes, we have switches to enable certain features, but not silent behavior changes.

            It's not perfect, but the forest of such switches in C compilers motivated D to not have them.

        2. cryptonector · · focus · HN ↗
          Alternatively every flag that changes the semantics of the code is a workaround for either legacy code no one will fix or language committee decisions that have unintended side effects.
          1. WalterBright · · focus · HN ↗
            Are C/C++ chars signed or unsigned? What a mess!
            1. nrr · · focus · HN ↗
              The state of affairs in C and C++ is abhorrently bad. Not only is there `char` but also `signed char` and `unsigned char`, and the standards seem to leave the signedness interpretation of bare `char` up to the implementation.

              Ada explicitly settled on `Character` being an enumeration type based on a specific character set encoding. When I learned Ada 95, the ARM specified the ISO 8859-1 character set for `Character`, likewise with `Wide_Character` and `Wide_Wide_Character` explicitly settling on 16- and 32-bit implementations of UCS. I wish more language specifications made decisions like this.

              D following suit with tying its `char`, `wchar`, and `dchar` to UTF-8, UTF-16, and UTF-32 is commendable.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.