201–210 of 233 posts
Earlier quoted context omitted.
It should also warn if there are infinite loops, so the dev can know whether it will ever halt.
Infinite loops are undefined behavior in C++.
Hence for(;;) std::this_thread::sleep_for(1s) is not UB.
C is even more lenient.
UB is not allowed in a constant expression in c++, which is a good reason to put constexpr in front of as many things as you can.
It's still super useful though, and more common language UBs are caught.
13. But if the line with UB isn't executed, then the program will work normally as if the UB wasn't there. 14. Okay, but if the line with UB is unreachable (dead) code, then it's as if the UB wasn't there. 15. If the line with UB is unreachable code, then the program won't crash because of the UB. 16. If the line with UB is unreachable code, then the program will at least stop running somehow and at some point. This…
> This is nonsense. The line with UB has to be reached for the execution to be undefined. Check the footnote at item 14, it links to a page which shows one example of how a line with UB can be reached (basically: the optimizer can reorder the code so that parts of the line with UB will run much earlier than you'd expect).
> Right now, we have the fundamental principle that dead code cannot affect program behavior.
13. But if the line with UB isn't executed, then the program will work normally as if the UB wasn't there. 14. Okay, but if the line with UB is unreachable (dead) code, then it's as if the UB wasn't there. 15. If the line with UB is unreachable code, then the program won't crash because of the UB. 16. If the line with UB is unreachable code, then the program will at least stop running somehow and at some point. This…
Looks like you believe in some falsehoods most programmers believe about UB. Well, you are not alone.
> Right now, we have the fundamental principle that dead code cannot affect program behavior.
Earlier quoted context omitted.
I think memcpy is fine because it operates on a special type that is allowed to alias anything. Strict aliasing has other fun issues like the impossibility of implementing malloc-like functions or the lack of any requirement for access to non-char members of structs to work at all[0]. [0]: https://stackoverflow.com/questions/49298704/how-reason-abou...
memcpy is UB because it reads padding bytes in structs. memmove fails as it requires pointer comparisons between separate allocations, which is UB.
Comparing unrelated pointers is unspecified, not undefined. It's also an implementation detail of memmove. It can use a magical total order comparison of pointers that is otherwise unavailable to users of the language.
- Compilers and language designs could not improve on this situation without sacrificing performance or portability.
13. But if the line with UB isn't executed, then the program will work normally as if the UB wasn't there. 14. Okay, but if the line with UB is unreachable (dead) code, then it's as if the UB wasn't there. 15. If the line with UB is unreachable code, then the program won't crash because of the UB. 16. If the line with UB is unreachable code, then the program will at least stop running somehow and at some point. This…
So we could say, unreachable UB is fine, but if you do reach it, then it doesn't matter when you reached it.
Earlier quoted context omitted.
> gcc screwing the developer over because it was UB when they thought it was just implementation defined No, the developer thought "UB" produced an integer with an undefined (but still valid integral?) value. They misunderstood what UB is, not whether or not something was UB.
That's from the spec POV. On x86 for example, signed int overflow is well defined.
Earlier quoted context omitted.
Yeah they are and that's too bad. HWASan is another option that reduces the overhead but would only work on a core that had MTE (which your microcontroller is not as likely to have).
Actually it is an enhanced armv7 which might work. Though officially HWASan requires armv8. Besides that we have Zephyr stack and heap overflow detection, but it is not quite as accurate as ASan, and does not handle cases UBSan does.
UB is not allowed in a constant expression in c++, which is a good reason to put constexpr in front of as many things as you can.
While theoretically true, there are a whole bunch of undefined behaviors that are not caught in constexpr context in practice. In particular unsequenced operations on the same object are typically not caught. It's still super useful though, and more common language UBs are caught.