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. rfgplk · 1789750722 · focus · HN ↗
  It's catastrophic actually. Like disastrously catastrophic. It started with C++20 mostly, and has only kept getting worse from then. See zero initializing variables by default (WHY?) compare/meta including half the STL and HARDCODING those symbols, std::initializer_list being in the std namespace (if you don't include <initializer_list> you literally can't use it, and there is no such thing as a __initializer_list or some internal symbol), the entire coroutine library where you MUST provide coroutine_handle, noop_coroutine, suspends et al (coroutines aren't that bad because they're not necessarily spaghetti).
  <meta> is the single WORST OFFENDER, where they hardcode std::vector (literally std::vector in the std namespace) std::ranges std::allocator.
  1. aw1621107 · 1789757157 · focus · HN ↗
    > See zero initializing variables by default
    Strictly speaking the standard only requires some pattern that is not tied to program state. Zero works for that, but so do other static patterns like 0xABAB... or the like.
    > (WHY?)
    The motivation section of the corresponding paper [0] might be interesting. tl;dr: it lets wrong code be wrong without suffering from (all) the consequences of full-blown UB.
    [0]: <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2795r5.html#motivation" rel="nofollow">https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...
    TuxSH · 1789824043 · focus · HN ↗
    AFAIK zero-init is unfortunately the default compiler use (but you can change that)

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.