Thread

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

173 points · 290 comments · ibobev

wahern · 1789747013 · focus · HN ↗
> When both conditions are met, the loop body is replaced with a call to std::this_thread::yield(). This gives execution of the loop the forward-progress semantics it previously lacked.
That's the epitome of the hidden code downside that Linus and many others dislike about C++. For constructors and destructors it's somewhat unavoidable and not so random, though Rust does better at limiting the blast radius of non-local code, at least in the drop case.
If they didn't want to adopt the C11 rule, the C++ committee should've explored a rule that required the compiler to emit a diagnostic or error for trivial loops (whether as defined by C11 or otherwise), requiring the programmer to explicitly insert ::yield or similar. No hidden code, and less opportunity for the compiler to do surprising things.
The C committee has been rigorously enumerating UB cases in the standard and addressing each case in turn, often by requiring a diagnostic, error, or by turning it into implemention defined behavior. But inserting code like that would be unthinkable.
1. kevin_thibedeau · 1789769126 · focus · HN ↗
  The C++ committee has a habit of thumbing its nose at standard practice. They intentionally broke bitwise operators on volatiles because they wanted to be impose their atomic religion everywhere. Then they had to walk that back after they broke every embedded library directly manipulating hardware registers.
  Empty infinite loops are also commonplace in embedded C once main is done with init and within exception handlers. They don't care about anything beyond their narrow systems programming worldview.
  1. Sniffnoy · 1789786015 · focus · HN ↗
    > They intentionally broke bitwise operators on volatiles because they wanted to be impose their atomic religion everywhere.
    Could you elaborate on this?
    aw1621107 · 1789791121 · focus · HN ↗
    "broke" is arguably an overstatement. C++20 deprecated some (most?) operations on volatile variables [0] in part because they can misleadingly imply an atomic operation:
    > volatile external modifications are only truly meaningful for loads and stores. Other read-modify-write operations imply touching the volatile object more than once per byte because that’s fundamentally how hardware works. Even atomic instructions (remember: volatile isn’t atomic) need to read and write a memory location []. These RMW operations are therefore misleading and should be spelled out as separate read ; modify ; write, or use volatile atomic operations which we discuss below.
    This was not received particularly well in the embedded community (e.g., [1]) due to said deprecation affecting compound bitwise operations on volatile variables, which are extremely widely used to interact with hardware registers. This pushback eventually resulted in C++23 un-deprecating compound bitwise operators on volatile variables [2].
    [0]: <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1152r0.html" rel="nofollow">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p11...
    [1]: <a href="https://www.reddit.com/r/cpp/comments/jswz3z/compound_assignment_to_volatile_must_be/" rel="nofollow">https://www.reddit.com/r/cpp/comments/jswz3z/compound_assign...
    [2]: <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2327r1.pdf" rel="nofollow">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p23...
    tialaramex · 1789809225 · focus · HN ↗
    Basically on a rare occasion somebody (JF Bastien) was able to land a C++ proposal which warns you if you'd do something stupid, and inevitably C programmers cosplaying as C++ programmers insisted "it's not stupid it's advanced" and so now C++ must not even warn you this is a bad idea.
    It still is a bad idea, but being warned would make them feel bad.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.