Right but my point is if you know what the compiler will do you can use UB. It might do different things for different optimizations but with flags you can tell it what you want it to do.
The thing is that this behavior will change when you change your compiler (and cause a bug, which can be quite nasty) and it can change literally after a minor compiler update. Thus the code technically works, but no one can guarantee that it will work tomorrow. This is hella bad
I'm not saying you look at the compiler source or dynamically learn its behavior. I'm saying the compiler devs document how something undefined will work and if they change it then they will put it in release notes and you will have to stick with the old compiler. If you're programming at this level then you have the ability fork the compiler to keep something while updating the rest. But if your compiler is working fine you also don't need to update it, if it's not broken don't fix it.
The only reason I can think of to use documented undefined behavior is so you don't have to use assembly or you've turned optimizations off and are doing that yourself.
I dont understand why would you use something that is not specified by the standard and go through hassle of making sure that your compiler (and everyone else's compilers) stay absolutely the same to prevent random bugs from appearing. And "if its not broken - dont fix it" defo doesnt apply to system updates. Just write proper code, use analyzers, and your code will at least work in the same way on all platforms, why bother with using ++i and i++ in the same expression?
TLDR to stop the chain from falling into a dumb argument: UB should NOT be used. This is NOT how real world software gets written. In your own projects - of course, do whatever you want.
You would not make sure other people's compilers do the same thing. There is also implementation defined where the c spec lists all the options a compiler could do.
You would say to users to only compile the program with a specific version or you would have your customized fork even. And you would be saying xyz that isn't defined by the c spec is defined for your fork so you can be sure that what works for -O0 works for -O3.
If there were never any reason to use UB, then compilers should have strict checking as the default option. Division by zero for example doesn't need an if statement slowing your code down. If it occurs the CPU causes an interrupt and execution should halt.
Not all UB is useful to use like array access out of bounds.
As I said before you'd have to be doing really low level stuff go even consider this and you wouldn't fork the compiler just for this. Using assembly is probably the better option until it becomes more efficient to make your own compiler infrastructure.
0
u/HyperWinX C++ 16d ago
They can. And they implement whatever standard says to implement. Everything that is not defined by the standard is undefined behavior.