compilers be like

[u/luciferoussky72]

[u/HyperWinX]

They dont "see" undefined behavior though. Because... it is undefined.

[u/scalareye → u/HyperWinX]

They do, the dev can implement whatever they want the compiler to do with that code

[u/HyperWinX → u/scalareye]

They can. And they implement whatever standard says to implement. Everything that is not defined by the standard is undefined behavior.

[u/scalareye → u/HyperWinX]

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.

[u/HyperWinX → u/scalareye]

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

[u/scalareye → u/HyperWinX]

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.

[u/HyperWinX → u/scalareye]

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.

[u/scalareye → u/HyperWinX]

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.

[u/luciferoussky72 → u/scalareye]

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

[u/scalareye → u/[deleted]]

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.

[u/luciferoussky72 → u/HyperWinX]

True lol

[u/Kenkron]

Rust users: Allow us to introduce ourselves

[u/luciferoussky72 → u/Kenkron]

*unsafe block standing right behind you*

[u/Kenkron → u/luciferoussky72]

Dude, it was totally necessary to makey own double -linked list, which I need to make my blazingly fast leftpad replacement library! And I'm sure I made no mistakes, because I told Claude "make no mistakes".

[u/luciferoussky72 → u/Kenkron]

Whenever I see 500 lines of Rust I think that it could be 50 lines of functionally identical C++ lol

[u/RedAndBlack1832]

They actually just assume it won't happen which leads to... interesting behaviour. You can set up situations in which you get calls that were never made this way but the most obvious example is just integer overflow lol. If you assume overflow never happens that can cause weird optimizations that won't work very well if you do actually get overflow

[u/luciferoussky72 → u/RedAndBlack1832]

Well, yeah. Although do keep in mind that it’s only signed overflow that’s UB. It’s UB specifically because it lets the compiler assume that x + n is always greater than x when x is signed. Unsigned overflow is defined and it just wraps back to 0

[u/scalareye → u/RedAndBlack1832]

What do different compilers do if signed overflow or underflow happens. Can you tell the compiler to act in a specific way for different undefined behaviors. I know you can enforce strict checking so it won't do some of the extra optimizations

It's also fine with floating point numbers but your code won't like the result either.

If you were making an integral calculator for example, you should accept input as a string and reject invalid strings.

Floating points have signed infinity for their maximum value and all of your computations will end up collapsing to infinity. Can also get NaN for 0 / 0 and that also ruins your computation without telling you when it happened. You can tell the compiler to error out if it happens though.

[u/luciferoussky72 → u/scalareye]

So, the reason it was initially undefined behaviour is because for a long time the C and C++ standard didn’t specify *how* to store numbers. Things like endianness being inconsistent meant you couldn’t make signed overflow defined behavior without standardizing a bunch of other things.

Ironically, C++17 actually did standardize how to store numbers, but signed overflow remained undefined behavior for optimization reasons. For example, having it undefined means the compiler can assume that x + n is greater than x and optimize around that.

[u/RedAndBlack1832 → u/luciferoussky72]

The last paragraph is what i meant to be getting at :)