3 ms·
I do agree that the story around UB in C and C++ sucks. But UB doesn't exist because the compiler engineers want to be able to stick in optimizations. Once they
by UncleMeat 4y ago
I do agree that the story around UB in C and C++ sucks. But UB doesn't exist because the compiler engineers want to be able to stick in optimizations. Once they are in the spec it makes sense to follow the rules but most UB comes from a desire for portability and to not privilege one platform over another.
And further, defining a lot of UB won't actually improve things. Imagine we define signed integer overflowing behavior. Hooray. Now your program just has a different bug. If you've accidentally got signed integer overflow in your application then "did some weird things because the compiler assumed it would never overflow" is going to cause exactly the same amount of havoc as "integer overflowed and now your algorithm is almost certainly wrong."
- nayuki 4y ago> And further, defining a lot of UB won't actually improve things. Imagine we define signed integer overflowing behavior. Hooray. Now your program just has a different bug. This is exactly what JF Bastien argues in his hourlong talk: https://youtu.be/JhUxIVf1qok?t=2284 https://youtu.be/JhUxIVf1qok?t=2284 So yeah, defining signed integer overflow isn't going to fix bugs in the vast majority of existing programs. That being said, enforcing signed overflow wraparound at least makes debugging easier because it's reproducible. This is how it is in Java land - int overflow wraps around, and integer type widths are fixed, so if you trigger an overflow while testing then it is reliably reproducible across all conforming Java compiler and VM versions and platforms.
- UncleMeat 4y agoIt also makes tools less able to loudly yell at you for having it in your application. Yes, you can turn on optional warnings if you want but if you've got one or two intended uses for this behavior then now you need suppressions and all sorts of mess.