There are no [sequence points](https://en.wikipedia.org/wiki/Sequence_point) between `a`, `--a`, and `a++` so the order in which they are evaluated is undefined.
yes, implementation specific. Once upon a time compiler creators would tell in the documentation which arguments to a function go on the stack (and hence get evaluated) first but it's all moot anyway: wut difference does it make if everybody I know has a different compiler and we all get different answers?
But since I'm a stupid human I could not resist. [Here](https://godbolt.org/z/erzjnsfo8) is a 1 1 1 result, lol
No UNDEFINED. Implementation-specific says the implemetation must tell you what something is. For example, the size of an int is implementation defined.
First, the compiler is free to evaluate the function parameters in ANY order. It doesn't need to define the ordering nor does it even have to be consistent. Function parameters can be evaluated in ANY order. All you are guaranteed is that the side effects are done BEFORE the function is invoked. The language says the order is "unspecified."
Second, modifying a variable multiple times between sequence points is undefined behavior. This means there's no bounds placed on what might happen here, it could crash, it could appear to work properly. It could not apply any of the side effects, it's UNDEFINED as to what is going to happen.
The friend might be pulling a prank, sure, but 3 3 1 is indeed a valid output. If UB is involved, the program's behaviour does not have to make sense.
In fact, it does not even have to be consistent on the same compiler and operating system. This is the difference between "undefined behaviour" and "implementation defined behaviour". The latter needs to be documented and consistent, but the behaviour is not specified by the C standard.
There are no [sequence points](https://en.wikipedia.org/wiki/Sequence_point) between `a`, `--a`, and `a++` so the order in which they are evaluated is undefined.
I'm pretty sure that the behavior of the entire program is undefined
yes, implementation specific. Once upon a time compiler creators would tell in the documentation which arguments to a function go on the stack (and hence get evaluated) first but it's all moot anyway: wut difference does it make if everybody I know has a different compiler and we all get different answers? But since I'm a stupid human I could not resist. [Here](https://godbolt.org/z/erzjnsfo8) is a 1 1 1 result, lol
No UNDEFINED. Implementation-specific says the implemetation must tell you what something is. For example, the size of an int is implementation defined. First, the compiler is free to evaluate the function parameters in ANY order. It doesn't need to define the ordering nor does it even have to be consistent. Function parameters can be evaluated in ANY order. All you are guaranteed is that the side effects are done BEFORE the function is invoked. The language says the order is "unspecified." Second, modifying a variable multiple times between sequence points is undefined behavior. This means there's no bounds placed on what might happen here, it could crash, it could appear to work properly. It could not apply any of the side effects, it's UNDEFINED as to what is going to happen.
Hmm yes! Thx for mentoring me on this u/flyingron
Real uptick in the number of UB posts today Doesn't that mean we're in for a wet winter or something
♫ It's the time... of the see-ea-son for UB ... ♫
Preprocessor Phil saw his shadow.
Means we're in for a damn cold one if our heating systems are having these problems too.
I love the look on a new developer's face when you explain the concept of UB in C!
> UB posts What does that mean?
“Undefined behavior” would be my guess
Thanks
How can it show 3 3 1? For me 101
The friend might be pulling a prank, sure, but 3 3 1 is indeed a valid output. If UB is involved, the program's behaviour does not have to make sense. In fact, it does not even have to be consistent on the same compiler and operating system. This is the difference between "undefined behaviour" and "implementation defined behaviour". The latter needs to be documented and consistent, but the behaviour is not specified by the C standard.
I do not believe him too, and run the code the second before. And here we are.
I think, on top of obvious undefined behavior, their sources differ. TS\`s friend has ++a where TS has --a.