They're wrong because they're showing how your implementation decided to implement this undefined behavior, this time, and don't reflect on how C works.
C programs are understood in terms of the CAM (C Abstract Machine).
The compiler's job is to build a program that produces the same output as the CAM would for a given program.
The CAM says that a variable can only be read, or read-to-modify, once between two sequence points.
There are no sequence points between the i++ and i+1, so this produces a read/write conflict, which means that the program has undefined behavior in the CAM, and so the compiler can do whatever it wants.
It could crash, or print out 23, 37 or -9, 12, and these would all be equally correct behaviors.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is one of the reasons I write prototypes and tests. I'll try it.
In that case, I think you missed the point -- but I look forward to explaining why your results are wrong. :)
It's funny. First using i, then increment i, then use i as a second parameter.
The result is the same:
Your results are wrong. :)
They're wrong because they're showing how your implementation decided to implement this undefined behavior, this time, and don't reflect on how C works.
C programs are understood in terms of the CAM (C Abstract Machine).
The compiler's job is to build a program that produces the same output as the CAM would for a given program.
The CAM says that a variable can only be read, or read-to-modify, once between two sequence points.
There are no sequence points between the i++ and i+1, so this produces a read/write conflict, which means that the program has undefined behavior in the CAM, and so the compiler can do whatever it wants.
It could crash, or print out 23, 37 or -9, 12, and these would all be equally correct behaviors.