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.
Well, lots of “undefined behavior” that ends up working in practice can still cause subtle bugs. Take C-style type punning. Where you type “long y = * (long*) &x;” when x is a double. Technically, it works, but the compiler is actually allowed to assume that pointers of different types* can’t point to the same memory address, so type punning can cause subtle bugs if you use it in the wrong place. Plus, there are better alternatives like memcpy, C++ reinterpret_cast, etc.
*with the exception of char* and void*, which can “alias” (the technical term for pointer overlap rules) any other type
I know but that It's not about detection of undefined behavior. You can tell the compiler to throw an error if division by zero happens. It doesn't need to be a check built into the program so it runs safely. The CPU instruction itself causes an interrupt that you have to handle otherwise the program crashes.
My only point was that the compiler does make code for the undefined behavior, not checks for when it happens.
At runtime it could have built into the error handler that division by zero makes the result of the computation the largest possible number for the type or the computation gets skipped by the error handler and the program keeps running now with junk data.
3
u/HyperWinX C++ 17d ago
They dont "see" undefined behavior though. Because... it is undefined.