Timeline for What are the conditions necessary for a programming language to have no undefined behavior?
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 21, 2023 at 18:44 | comment | added | Peter Cordes | (Some people, especially @supercat, argue that the original designers of C assumed compiler devs would treat most cases of UB like that when it made sense for the target machine, not that they were giving license to compilers to reject or "break" some code on all platforms just because some don't have meaningful definitions. e.g. pointer comparison on unrelated pointers makes sense on machines with a flat memory model, but to do it portably and safely even on such machines you have to cast to uintptr_t.) | |
| Aug 21, 2023 at 18:39 | comment | added | Peter Cordes | My general point being that "implementation-defined" behaviour (like some things are in C, such as (int32_t)my_int64 for out-of-range values) is the middle ground between full UB and something like Java where the language requires the same result on every implementation. You're guaranteed to get some value and not break surrounding code. | |
| Aug 21, 2023 at 18:38 | comment | added | Peter Cordes | C++ leaves the behaviour undefined in cases where it could easily make it implementation-defined. e.g. x <<= n; (variable-count shift) is fully undefined for shift counts greater than the type width. If that happens anywhere in your program, everything before and after that might not work as expected. (And in modern C++, optimizers could assume a value-range for n of 0 to 63 or whatever). If instead C++ had required each implementation to define the rules for that case, any given build of a program would have some behaviour, like on x86 wrapping the shift count, or ARM producing 0. | |
| Aug 19, 2023 at 10:56 | history | answered | Steve | CC BY-SA 4.0 |