▲ | laauraa 4 days ago | ||||||||||||||||
>Uninitialized data They at least fixed this in c++26. No longer UB, but "erroneous behavior". Still some random garbage value (so an uninitialized pointer will likely lead to disastrous results still), but the compiler isn't allowed to fuck up your code, it has to generate code as if it had some value. | |||||||||||||||||
▲ | tialaramex 4 days ago | parent | next [-] | ||||||||||||||||
It won't be a "random garbage value" but is instead a value the compiler chose. In effect if you don't opt out your value will always be initialized but not to a useful value you chose. You can think of this as similar to the (current, defanged and deprecated as well as unsafe) Rust std::mem::uninitialized() There were earlier attempts to make this value zero, or rather, as many 0x00 bytes as needed, because on most platforms that's markedly cheaper to do, but unfortunately some C++ would actually have worse bugs if the "forgot to initialize" case was reliably zero instead. | |||||||||||||||||
| |||||||||||||||||
▲ | kazinator 4 days ago | parent | prev | next [-] | ||||||||||||||||
C also fixed it in its way. Access to an uninitialized object defined in automatic storage, whose address is not taken, is UB. Access to any uninitialized object whose bit pattern is a non-value, likewise. Otherwise, it's good: the value implied by the bit pattern is obtained and computation goes on its merry way. | |||||||||||||||||
▲ | account42 4 days ago | parent | prev [-] | ||||||||||||||||
That's unfortunate. |