Thread: Help with Pre and Post Increment !

> Try above programm's and i bet they will give same output in any compiler.
Just go and read the link to my other thread in post #4

Fed up with this kind of BS from know-nothings, I did an experiment with the same code and many compilers.
It's the same kind of broken code as you've posted, and the results are DIFFERENT.

You just lost the bet - pay up and then shut up.

The C standard tells you you're wrong.

All the regulars (with a combined programming experience of 100's of years and most of the compilers you're ever likely to see) tell you you're wrong.

Any sane person might start to question their supposedly infallible source material and start doing a bit more independent research, rather than relying on what one book and one compiler is telling you.

Originally Posted by raviwagh

but i think i know the that part and i think it is associated with precedence of c operators.

Related, but not the same. Precedence specifies grouping, not order of evaluation. This is about order of evaluation and about undefined behaviour when you have operations that are unsequenced relative to each other and yet affect the same object.

Originally Posted by Salem

> Try above programm's and i bet they will give same output in any compiler.
Just go and read the link to my other thread in post #4

Fed up with this kind of BS from know-nothings, I did an experiment with the same code and many compilers.
It's the same kind of broken code as you've posted, and the results are DIFFERENT.


You just lost the bet - pay up and then shut up.

The C standard tells you you're wrong.

All the regulars (with a combined programming experience of 100's of years and most of the compilers you're ever likely to see) tell you you're wrong.

Any sane person might start to question their supposedly infallible source material and start doing a bit more independent research, rather than relying on what one book and one compiler is telling you.

yeah its true they give different answers i have tried with code blocks, turbo c and dev c++ they all gave me different answer.
then i modified the code and declared the variable i outside of main and they all give me same result, thus i think those compiler to deal with variable scope.

then i modified the code and declared the variable i outside of main and they all give me same result, thus i think those compiler to deal with variable scope.

More irrelevant nonsense.

If the same code produces different answers when compiled with different compilers, or produces different answers simply by moving variables around in memory, then for all practical purposes, it means there is a bug in the code.

Here's another link for you to seemingly ignore.
Expressions

Originally Posted by raviwagh

its not bug, int i's storage class is changed by moving the int i outside of the main, and storage classes can give different answers by moving the same code.

That is true in the specific case where a variable was not explicitly initialised and then used: if the object has static storage duration, such as by virtue of being global, then it would be zero initialised so its use would be fine. If the object had automatic storage duration instead then its value would be indeterminate. However, other than this, the usage of a variable in an expression should have the same net effect regardless of the object's storage duration, otherwise you have a bug.

Originally Posted by raviwagh

the compilers default variable scope can be different

No, the notion of scope is in the standard. We can always identify the scope of a variable and know that that is how any conforming compiler will treat it.

Originally Posted by raviwagh

it is the undefined behavior and it can produce different answer with different compilers.

There is actually a difference between undefined behaviour and unspecified behaviour:

Originally Posted by C11 Clause 3.4.3

undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements

NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

EXAMPLE
An example of undefined behavior is the behavior on integer overflow.

Originally Posted by C11 Clause 3.4.4

unspecified behavior
use of an unspecified value, or other behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance

EXAMPLE
An example of unspecified behavior is the order in which the arguments to a function are evaluated.

What this means is that if you call a function like this:

Code:

f(x(), y());

then whether x is called first or y is called first is up to the compiler. So, if say you print something to standard output in x and also in y, which gets printed first is up to the compiler. So, this is a possible bug, but it is not undefined behaviour.

On the other hand, for the code in posts #1 and #3, it is not only unspecified behaviour, but undefined behaviour. This means that although jimblumberg's compiler was nice enough to warn about it, the compiler could well have simply refused to compile.

Originally Posted by raviwagh

but compiler compiled that why is that??

Perhaps because the check is/was only enabled at a higher warning level, so it would be more consistent to always compile rather than to only compile when warning level is low.