3 ms·
Yeah this issue is super obvious and non-controversial. Uninitialized state is totally fine as an opt-in performance optimization. But having a well defined no
by forrestthewoods 10mo ago
Yeah this issue is super obvious and non-controversial.
Uninitialized state is totally fine as an opt-in performance optimization. But having a well defined non-garbage default value should obviously be the default.
Did C fuck that up 50 years ago? Yeah probably. They should have known better even then. But that’s ok. It’s a historical artifact. All languages are full of them. We learn and improve!
- deleted 10mo ago[deleted]
- 1718627440 10mo agoI don't know, I expect all variables to be uninitialized until proven otherwise. It makes it easier for me to reason about code, especially convoluted code. But I also like C a lot and actually explicitly invoke UB quite often, so there is that.
- forrestthewoods 10mo agoI like C and it's great. I wish more people wrote C instead of C++. But there's a reason that literally no modern language makes this choice. If uninitialization was opt-in you would still be free to "assume uninitialized until proven otherwise". But uninitialized memory is such a monumental catastrophic footgun that really is not a justifiable reason to make that default behavior. Which, again, is why no modern languages make that (terrible) design choice.
- 1718627440 10mo agoI am talking about random convoluted code, I did neither wrote nor control. The UB does not only help the compiler, it also helps me the reverse engineer, since I also can assume that an access without a previous write is either a bug, or I misinterpreted the control flow.
- AlotOfReading 10mo agoYou can assume whatever initialization you want when reading code, even if it's not in the standard. Is your concern that people would start writing code assuming zero-init behavior (as they already do)? That purpose would be better served by reclassifying uninitialized reads as erroneous behavior, which they are for C++26 onwards. What useful purpose is served by having them be UB specifically?
- torstenvl 10mo agoUB doesn't mean there will be nasal demons. It means there can be nasal demons, if the implementation says so. It means the language standard does not define a behavior. POSIX can still define the behavior. The implementation can still define the behavior. Plenty of things are UB just because major implementations do things wildly differently. For example: realloc(p, 0) Having initialization be UB means that implementations where it's zero cost can initialize them to zero, or implementations designed for safety-critical systems can initialize them to zero, or what have you, without the standard forcing all implementations to do so.
- AlotOfReading 10mo agoAll of that implementation freedom is also available if the behavior is erroneous instead. Having it defined as UB just gets you nasal demons, which incidentally this rule leads to on modern compilers. For example: https://godbolt.org/z/ncaKGnoTb https://godbolt.org/z/ncaKGnoTb
- forrestthewoods 10mo agoYeah that’s just really bad language design. Which, again, literally no modern languages do because it’s just terrible horrible awful no good very bad design.
- 1718627440 10mo agoIt's describing rather than prescribing, which yeah isn't really design. Most modern languages don't even (plan to) have multiple implementations, much less a standard.
- kevin_thibedeau 10mo agoThere are non-standard mechanisms to control variable initialization. GCC has -ftrivial-auto-var-init=zero for zero-init of locals (with some caveats). For globals, you can link them into a different section than bss to disable zero-init.