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...
    fc417fc802 · 1789767692 · focus · HN ↗
    In other words, it's a sane default that you can opt out of on a case by case basis which is the way it should have been all along.
    WalterBright · 1789769436 · focus · HN ↗
    D initializes floating point variables to NaN by default. And chars to 0xFF. Yes it's controversial!
    dahart · 1789779641 · focus · HN ↗
    I’d guess the concern is performance, not what initializer value is used. And performance is a valid concern that is discussed in the proposal, and a reason there’s an escape hatch. Still, it might cause some confusion.
    TuxSH · 1789824043 · focus · HN ↗
    AFAIK zero-init is unfortunately the default compiler use (but you can change that)
  2. mitxela · 1789777701 · focus · HN ↗
    I can't find anything saying variables are zero initialized by default in C++20. But the reason to do so is obvious: many bugs are caused by the lack of this, and as long as you can opt out with "= void" or something, it's not violating C++ core principles.
    dahart · 1789779523 · focus · HN ↗
    They were saying the problematic philosophy started in C++ 20, not the variable initialization rule.
    Yes the reason is obvious, but it’s neither simple nor black and white. One huge problem is that this can cause serious performance regressions, and you have to change your code to opt out, e.g. add “[[indeterminate]]”. There are many, many cases in high performance computing where the intended & desired behavior is don’t touch my variables until I fill them.
    This is changing C++ core principles, there’s a new designation for the state of a variable: erroneous. It’s also subtle and weird, because you can still have well-defined behavior even with erroneous state. It does seem like this might be an experiment though, I don’t think this is the end of the story. (It seems they’re already talking some redesign of this idea.)
    ack_complete · 1789780786 · focus · HN ↗
    What I'm most annoyed at with the variable initialization change is that:
    - It's potentially a performance change in every single function, especially ones that have sizable fixed-size buffers - If you have regressions you have to spray [[indeterminate]] everywhere, because there is no coarser way of suppressing it. - While the language says unrecognized attributes are ignored, compilers frequently warn on unrecognized attributes. Clang, for instance, currently warns on [[indeterminate]]. - There is no defined macro name for backwards compatibility.
    Which means that libraries are going have to all declare their own macros for [[indeterminate]] and pepper their code with it.
    mitxela · 1789785386 · focus · HN ↗
    Uninitialized variables were already UB to read, because some architectures have trap representations, even for integers. Every register on Itanium has one.
    cryptonector · 1789793319 · focus · HN ↗
    That's not reason enough to have the compiler initialize.
    zrm · 1789796870 · focus · HN ↗
    That's assuming you were reading it without writing to it. There are three common cases when that isn't true.
    The first is that you have a fixed buffer large enough for the maximum message size even though the typical ones aren't that big. You most often write 1% of the buffer and read it back, the other 99% is never accessed.
    The second is that you always write the entire contents before reading it but the compiler may not be able to see that.
    And the third is that you have a code path where that variable is simply not used.
    You would then have the compiler emitting instructions to write zeros that are either overwritten before being read or are never read at all.
    Moreover, zero initializing the data doesn't actually remove the bugs when that isn't the case. Consider the first case when you mess up. You have a fixed buffer used to store variable length messages. For the first message the buffer is now zeros instead of uninitialized, but for every subsequent message the remainder of the buffer still contains the remainder of the previous message and subjects you to information disclosure or data modification if you're reading back a different amount than was written in the associated call.
    Now consider the second or third case. You unintentionally read from a variable before assigning to it. You get zeros instead of uninitialized memory, but if you weren't expecting zeros, well, the UID field is now 0.
    mitxela · 1789822839 · focus · HN ↗
    If you are writing to it before reading from it then it's not uninitialised, and in 99% of cases the compiler can see that and will not set it to 0 at its declaration because that's a dead store.
    zrm · 1789871243 · focus · HN ↗
    Consider this (quite common) code:
    char buffer[LARGE_SIZE]; if(maybe_fill_buffer(buffer, sizeof(buffer))) { use_result(buffer); }
    The function maybe_fill_buffer() is an external library function that either fills the buffer and returns true or doesn't access it and returns false. Or maybe it unconditionally fills it, or unconditionally returns false without reading from it. The compiler can't see any of that though because it's in an external library. For all it knows that function is going to read from it instead of writing to it.
    Notice that if it could actually figure it out 99% of the time then it could also emit a warning the 1% of the time that it can't and encourage you to make an explicit choice, which would have been a better option if that was actually the rate.
    nullc · 1789798187 · focus · HN ↗
    Zero initializing also hides bugs.
    Say you have some code that should not be reading the initial state and is buggy if it does. Without zero-init, valgrind and msan will give you an immediate and false positive message that your code is wrong-- or forget dynamic analysis: the compiler can often statically tell you that the code will use an uninitialized variable. Zero initialize it and you lose that signal.
    paulf38 · 1790087132 · focus · HN ↗
    "valgrind and msan will give you an immediate and false positive message"
    Why a false positive? Are you one of those people that 'knows' that their code is correct and always blames the tool? What you describe sounds like a real error. Sort of. The error is not triggered by reading the value, it gets triggered when it is used in some conditional context and the undefinedness has an observable impact on the execution of the program.
    This is a change from undefined/erroneous behaviour to something else - defined but maybe not what you wanted.
    I agree that this can make error analysis more difficult.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.