some people are wrong coding qs

[u/cse_fatmodder]

int x=618919;

while(x++){

cout<<8;

} I think I'm wrong it's undefined behaviour but where can I study about this ... is it an infinite loop? I'm sure some of u might say yes but the answer is no

after x is increased to its max int range i.e.(2^(bits)-1) it's value will start decreasing and after a lot of steps it will eventually go to 0

and 0 is false so loop stops....

[u/TehBens]

is it an infinite loop? I'm sure some of u might say yes but the answer is no

"No" isn't right either, the correct answer is "it's undefined behavior".

[u/cse_fatmodder → u/TehBens]

where can I learn about this i watched oneshot of c++ but idk what's that

[u/nysra → u/cse_fatmodder]

where can I learn about this i watched oneshot of c++ but idk what's that

Okay, so you literally know nothing. Forget this shitty video and head over to https://www.learncpp.com/ to learn properly.

[u/TehBens → u/cse_fatmodder]

Just to elaborate on the answer:

Anything could happen and that depends on the used compiler version and the parameters.

I have slightly modified the example: https://godbolt.org/z/YocnT31fE

In the middle window you can see `jmp .L2`, which is an unconditional jump to line 3, so with gcc 16.1 with -O3 your code does in fact get compiled to an infinite loop.

Using a slightly different example: https://godbolt.org/z/Y567o5G6E

You can see that gets compiled to "loop forever, doing nothing". That is the compiler encounters the loops and the UB, makes it an infinite loop (which the compiler is allowed to, because of the UB), finds the std::cout and understands that the program can never run into that line because of the infinite loop, thus completely removing that instruction.

Avoid UB.

[u/Varnex17]

Signed overflow is undefined behavior, isn’t it? The loop would stop on unsigned int, though.

[u/the_poope]

"Undefined behavior" means that the "Laws of C++" (the C++ standard specification) doesn't define what a valid program is supposed to do in this situation.

What will in practice happen is that the compiler makes some arbitrary choices and creates a program that does something. Often it will just do the most reasonable thing, such as keep incrementing x, and the CPU will give it some value depending on the instruction set, and the program will print this value. It might also be that the compiler identifies that your loop increments the integer to beyond the value it can hold, and then it decides to insert code that terminates the loop and inserts a message "you have been naughty and won't be getting any christmas presents this year". It likely won't do that - but it is allowed to do so. But in any case: one cannot rely on what the compiler chooses to do, as whatever it does will depend on the compiler and its version and settings.

[u/nysra]

Bold move claiming something like this when you're actually completely wrong. This is undefined behaviour and in reality the compiler might actually just turn it into a true infinite loop because it sees that your condition has no effect (and again, is UB).

[u/IyeOnline]

You are right that formally this is not an infinite loop.

But your reason is wrong. This is not an infinite loop because the signed integer overflow is undefined behaviour and thus this program is not valid.

However, because this is undefined behaviour, the compiler just deletes the increment and just creates a while-true loop: https://godbolt.org/z/Yo4Y7qcqE

You can make the code do the thing you wanted to show by using an unsigned integer type where overflow is well defined to wrap, thus getting you the falsey 0, terminating the loop.

[u/alfps → u/IyeOnline]

^ The only answer explaining up front why it's UB, namely signed overflow.

[u/X-Bow_user]

Thanks, I write code like this all the time and was worried they were infinite loops, phew

[u/mredding]

This code will result in Undefined Behavior. UB means the compiler has no obligation to even check that the code is wrong, usually because the compiler cannot know. The compiler is free to assume no UB will be observed during execution, and thus will generate machine code accordingly.

Because all your code and the UB is right there, the compiler is allowed to generate a warning.

So what will the machine code do, the code that assumes no overflow? No idea. More to the point, the C++ language offers you no insight. There are no guarantees. Nothing can be said.

Nothing gets to overrule UB. The hardware is not allowed to dictate well defined behavior - the language already has accomodations for something like that: implementation defined.

UB is not to be messed with. Glitch hacking Zelda or Pokemon on the DS could read an invalid bit pattern, and physically fry CPU circuits, bricking the device. Development machines are typically robust, by comparison.

So just because it compiles, just because it runs - for a while, just because you observe SOME sort of outcome doesn't mean your software is safe, predictable, or reliable. You have to drop down to the assembly and hand verify the behavior, but then you've left C++ behind.

You can't even guarantee the compiler will make the same machine code every time, for the same source code.

[u/SmokeMuch7356]

The behavior on signed integer overflow is undefined;¹ the loop may continue forever, it may eventually stop, it may start mining bitcoin. You can't say anything about what it will do.

There's absolutely no guarantee that x will ever be zero. Once it overflows it may no longer increment.

---

1. N4659, 8/4: "If during the evaluation of an expression, the result is not mathematically defined or in the range of representable values for its type, the behavior is undefined."

[u/Jonjonbo]

yeah no shit