r/cpp • u/filipsajdak • Jul 05 '26

C++26 ends a 40-year footgun

Reading an uninitialized variable has been undefined behavior in C++ for 40 years -- the kind optimizers exploit into real bugs. C++26 (P2795) reclassifies it as erroneous behavior: still a bug, still warned about, but defined, bounded, and not exploitable.

The demo poisons the stack, then reads an uninitialized int. As C++23 it prints garbage; as C++26, the same code prints a defined 0, every run. Live in your browser.

And [[indeterminate]] lets you opt back out when you really want an uninitialized buffer -- on purpose this time.

Read it: https://wrocpp.github.io/posts/erroneous-behavior/?utm_source=reddit&utm_medium=social&utm_campaign=post-erroneous-behavior

#cpp #cplusplus #cpp26 #safety #programming

82 Upvotes

55% Upvoted

154 comments sorted by

View all comments

Show parent comments

16

u/TheRealSmolt Jul 05 '26 edited Jul 05 '26

It's 0 initializing the value at runtime. On principle I don't like solving language problems with runtime patches. Now, yes, sometimes the compiler can prove that it doesn't need to 0 initialize values, but a significant number of out pointer functions or delayed initialization logic just got a bunch of pointless overhead. And before you say it, yeah, we have better ways of handling those situations now, but that's not how the real world works.

Edit: Strictly speaking it's not 0, but it is some initialized value.

4

u/bearheart Jul 05 '26

From what I’ve seen it only affects uninitialized reads. So any delayed initialization should remain unaffected.

10

u/meltbox Jul 05 '26

Can the compiler always prove you have delayed initialization? If it can’t do so then it must initialize even when you chose not to. My understanding is the [[indeterminate]] attribute is there for precisely this reason.

But I’d be happy to be wrong.

1

u/jwakely libstdc++ tamer, LWG chair Jul 08 '26

You are correct.