sir would you please tell me that why the following condition in 'C' is false?
main()
{
int i=1;
if(i<=i++)
printf("false");
else
printf("true");
}
It's not false, you just print false when it's true.
The comparison operator <= doesn't specify which side will be evaluated first, the i or the i++, and there is no sequence point at the end of the left-hand operand to a comparison function (see http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Sequence-Points).
If the left side is evaluated first, you get:
if (1 <= 1)
If the right side is evaluated first, you get:
if (2 <= 1)
This highlights the problem, but it's even worse than that.
You have written code with undefined behaviour, which means exactly that, "undefined". The compiler can do anything in this case and still be compliant with the standard.
For example, these compilers (with -O3) follow the else branch:
icc (ICC) 13.0.1 20121010
g++-4.8 (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1
While these compilers (with -O3) follow the true branch:
g++-4.7 (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3
g++-4.6
g++-4.5
g++-4.4
And other compilers could do something completely different.
This is a combination unspecified behavior and just plain and simple undefined behavior. So you can not predict the outcome of this code and the results can not be relied on. It is unspecified because in this line:
if(i<=i++)
we do not know whether the i or the i++ will be evaluated first. The draft C99 standard section 6.5 paragraph 3 says:
The grouping of operators and operands is indicated by the syntax.74) Except as specified later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation of subexpressions and the order in which side effects take place are both unspecified.
The above mentioned line also is undefined behavior because between sequence points we are only allowed to modify a variable once and if we modify it we are only allowed to read the previous value to determine the new value to set. In this case we are reading the prior value to determine both i and i++. From the draft standard section 6.5 paragraph 2:
Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.
To understand what your code is doing, I am going to re-write, only will be VERY explicit:
main()
{
int i=1;
if(i<=i) {
i++;
printf("false");
} else {
i++:
printf("true");
}
}
The i++ means to increment i after the comparison. In both branches of the if i is being incremented, so it is equivalent.
Related
I got different results for the following code with gcc and clang, I believe it is not a serious bug, but I wonder which result is more coherent with the standard? Thanks a lot for your reply.
I use gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0 and clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
#include <stdio.h>
int get_1(){
printf("get_1\n");
return 1;
}
int get_2(){
printf("get_2\n");
return 2;
}
int get_3(){
printf("get_3\n");
return 3;
}
int get_4(){
printf("get_4\n");
return 4;
}
int main(int argc, char *argv[])
{
printf("%d\n",get_1() + get_2() - (get_3(), get_4()));
return 0;
}
the result of gcc is
get_3
get_1
get_2
get_4
-1
and the result of clang is
get_1
get_2
get_3
get_4
-1
C does not impose an order in evaluating operands of some operators. The order of evaluation is imposed in C standard by sequence points. When you have sequence points present, a sound implementation of the language must finish evaluating everything at the left of the sequence point before it starts evaluating what is present in the right side. The + and - operators do not contain any sequence point. Here is the very definition from 5.1.2.3 p2
At certain specified points in the execution sequence called sequence points,all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.
In your expression
get_1() + get_2() - (get_3(), get_4())
you have the +, - and the comma , operator. Only the comma imposes an order of evaluation, the + and - does not.
The , between get_3() and get_4() is the only sequence point in printf("%d\n",get_1() + get_2() - (get_3(), get_4())); the get_x calls can happen in any order defined by the compiler as long as get_3() happens before get_4().
You're seeing the result of unspecified behaviour.
There's two different but related terms at play: operator precedence and order of evaluation.
Operator precedence dictates parsing order:
In your expression, the parenthesis has highest precedence so what's inside it belongs together.
Next we have the function call operators (). Nothing strange there, they are postfix and belong to their operator, the function name.
Next up we have binary + and - operators. They belong to the same operator group "additive operators" and have the same precedence. When this happens, operator associativity for operators of that group decides in which order they should be parsed.
For additive operators, the operator associativity is left-to-right. Meaning that the expression is guaranteed to be parsed as (get_1() + get_2()) - ....
And finally we have the oddball comma operator, with lowest precedence of all.
Once the operator precedence is sorted out as per above, we know which operands that belong to which operators. But this says nothing of in which order the expression will get executed. That is where order of evaluation comes in.
Generally C says, in dry standard terms:
Except as specified later, side effects and value computations of subexpressions are unsequenced.
In plain English this means that the order of evaluation of operands is unspecified, for the most part, with some special exceptions.
For the additive operators + and -, this is true. Given a + b we cannot know if a or b will get executed first. The order of evaluation is unspecified - the compiler may execute it in any order it pleases, need not document how, and need not even behave consistently from case to case.
This is intentionally left unspecified by the C standard, to allow different compilers to parse expressions differently. Essentially allowing them to keep their expression tree algorithm a compiler trade secret, to allow some compilers to produce more effective code than others on a free market.
And this is why gcc and clang give different results. You have written code that relies on the order of evaluation. This is no fault of either compiler - we should simply not write programs that relies on poorly-specified behavior. If you have to execute those functions in a certain order, you should split them up over several lines/expressions.
As for the comma operator, it is one of the rare special cases. It comes with a built-in "sequence point" which guarantees that the left operand is always evaluated (executed) before the right. Other such special cases are && || operators and the ?: operator.
This is an example from Deep C (slide 194)
int a = 41;
a++ & printf("%d\n", a);
The presentation claims that the result is undefined. Why? a is only assigned once between the sequence points. I think that the execution order between a++ and printf would be unspecified, so that this would print either 41 or 42 on all conforming compilers, with no undefined behavior.
In this line - a++ & printf("%d\n", a); there is only one sequence point (not counting what happens in function arguments - since a++1 happens in this line itself) - modifying a variable and reading from it at the same time within a single seqeunce point is UB. Behavior is undefined if a previous value is read from the object but there is a modification too, as in i * i++
&& is a sequence point, & is not a sequence point if that is where you were confused.
A sequence point is a point in time at which the dust has settled and all side effects which have been seen so far are guaranteed to be complete. The sequence points listed in the C standard are:
at the end of the evaluation of a full expression (a full
expression is an expression statement, or any other expression which
is not a subexpression within any larger expression);
at the ||, &&, ?:, and comma operators; and
at a function call (after the evaluation of all the arguments, and just before the actual call).
The Standard states that
Between the previous and next sequence point an object shall have its
stored value modified at most once by the evaluation of an expression.
Furthermore, the prior value shall be accessed only to determine the
value to be stored.
The bitwise operator & doesn't introduce a sequence point, so that is indeed undefined behavior.
I am confused between precedence of operators and want to know how this statement would be evaluated.
# include <stdio.h>
int main()
{
int k=35;
printf("%d %d %d",k==35,k=50,k>40);
return 0;
}
Here k is initially have value 35, when I am testing k in printf I think :
k>40 should be checked which should result in 0
k==35 should be checked and which should result in 1
Lastly 50 should get assigned to k and which should output 50
So final output should be 1 50 0, but output is 0 50 1.
You can not rely on the output of this program since it is undefined behavior, the evaluation order is not specified in C since that allows the compiler to optimize better, from the C99 draft standard section 6.5 paragraph 3:
The grouping of operators and operands is indicated by the syntax.74) Except as specified
later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation of subexpressions and the order in which side effects take place are both unspecified.
It is also undefined because you are accessing the value of k and assigning to it in the same sequence point. From draft standard section 6.5 paragraph 2:
Between the previous and next sequence point an object shall have its stored value
modified at most once by the evaluation of an expression. Furthermore, the prior value
shall be read only to determine the value to be stored.
it cites the following code examples as being undefined:
i = ++i + 1;
a[i++] = i;
Update
There was a comment as to whether the commas in the function call acted as a sequence point or not. If we look at section 6.5.17 Comma operator paragraph 2 says:
The left operand of a comma operator is evaluated as a void expression; there is a
sequence point after its evaluation.
but paragraph 3 says:
EXAMPLE As indicated by the syntax, the comma operator (as described in this subclause) cannot appear in contexts where a comma is used to separate items in a list (such as arguments to functions or lists of initializers).
So in this case the comma does not introduce a sequence point.
The order in which function arguments are evaluated is not specified. They can be evaluated in any order. The compiler decides.
This is undefined behaviour.
You may get any value. Lack of sequence points in two consecutive execution. Increase strictness level for warning and you will get warning: operation on ‘k’ may be undefined.
I recently came across a post What is the correct answer for cout << c++ << c;? and was wondering whether the output of
int c = 0;
printf ("%d %d", c++, c);
is also undefined??
I have studied in lectures that post-fix and prefix operators increment value only after getting a semicolon. So according to me, the output 0 0 is correct !!!
I have studied in lectures that post-fix and prefix operators increment value only after getting a semicolon.
Send your lecturer to me so that I can take a baseball bat to him politely point out his mistake.
Exactly when the side effect of either pre- or postfix ++ and -- is applied is unspecified, apart from the requirement that it happen before the next sequence point. In an expression like
x = a++ * b
a may be updated immediately after a++ has been evaluated, or the update may be deferred until a++ * b has been evaluated and the result assigned to x, or anywhere in between.
This is why expressions like i++ * i++ and printf("%d %d", c++, c) and a[i++] = i and a host of others are all bad juju. You will get different results based on the compiler, optimization settings, surrounding code, etc. The language standard explicitly leaves the behavior undefined so that the compiler is under no obligation to "do the right thing", whatever the right thing may be. Remember, the definition for undefined behavior is
3.4.3
1 undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
for which this International Standard imposes no requirements
2 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).
3 EXAMPLE An example of undefined behavior is the behavior on integer overflow.
This is a deliberate design decision - the rationale for leaving the order of these operations unspecified is to give the implementation freedom to rearrange the evaluation order for optimization purposes. However, in exchange for this freedom, certain operations will not have well-defined results.
Note that a compiler is free to try to detect these cases and issue a diagnostic; printf("%d %d", c++, c); would be easy enough to catch, but this would be a bugger to detect in the general case. Imagine if that had been written printf("%d %d", (*p)++, c); if p points to c, then the behavior is undefined, otherwise it's okay. If p is assigned in a different translation unit, then there's no way to know at compile time whether this is a problem or not.
This concept is not difficult to understand, yet it is one of the most consistently misunderstood (and mis-taught) aspects of the C language. No doubt this is why the Java and C# language specifications force a specific evaluation order for everything (all operands are evaluated left-to-right, and all side effects are applied immediately).
I have studied in lectures that post-fix and prefix operators increment value only after getting a semicolon
This is not how the standard describes it. A sequence point is a point in code in which side effects which may have occurred in previous parts of the code have been evaluated. The comma between arguments to a function is not a sequence point, so the behavior there is undefined.
The evaluation order of function arguments is unspecified. There is no guarantee that the arguments to a function will be evaluated in the order (1, 2, N), so there is no guarantee that the increment will be evaluated before the second argument is passed.
So according to me, the output 0 0 is correct !!!
No, the behavior is undefined, so you cannot reasonably claim that the output will be 0 0.
The behavior of the program is undefined because it has violated the requirements of 6.5 Expressions:
Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.
c++ and c are both evaluated without an intervening sequence point, and the prior value of c is read both to determine the value to be stored by c++, and to determine the value of the expression c.
The behaviour will be definitely undefined due to the undefined evaluation order of parameters. You can prove this "undefined output" doing some random testing:
printf("%d %d\n", c++, c);
// result: 0 1
printf("%d %d %d\n", c++, c, c++);
// result: 1 2 0
printf("%d %d %d %d\n", c++, c++, c++, c);
// result: 2 1 0 3
printf("%d %d %d %d\n", c++, c, c++, c);
// result: 1 2 0 2
printf("%d %d %d %d\n", c++, c, c, c);
// result: 0 1 1 1
You are right: it is undefined. The reason is that, though it is guaranteed that the three arguments to printf() will be evaluated before printf() is called, the sequence in which the three arguments are evaluated is undefined.
It is technically incorrect that the incrementation occurs only after the semicolon, incidentally. What the standard guarantees is that the incrementation will occur no later than the semicolon. [Actually, in your case, I believe that the standard guarantees that it will occur before control is passed to the printf() function -- but now this answer is starting to spin off into realms of pedantic trivia, so let me let the matter rest there!]
Anyway, in short, you are right. The behavior is undefined.
Update: As #R.. rightly observes, the undefined behavior comes from the lack of a sequence point between arguments. The standard is quite careful regarding the participles unspecified and undefined, so the correction is accepted with thanks.
This program exhibits a combination of both unspecified behavior and undefined behavior. Starting with the unspecified behavior, the draft C99 standard in section6.5 paragraph 3 says:
The grouping of operators and operands is indicated by the syntax.74)
Except as specified later (for the function-call (), &&, ||, ?:, and
comma operators), the order of evaluation of subexpressions and the
order in which side effects take place are both unspecified.
It also says except as specified later and specifically cites function-call (), so we see that later on the draft standard in section 6.5.2.2 Function calls paragraph 10 says:
The order of evaluation of the function designator, the actual
arguments, and subexpressions within the actual arguments is
unspecified, but there is a sequence point before the actual call.
So we do not know whether the read of C or the evaluation of C++ will happen first at this line of code:
printf ("%d %d", c++, c);
furthermore, in section 6.5.2.4 Postfix increment and decrement operators paragraph 2 says:
[...] After the result is obtained, the value of the operand is incremented. [...] The side effect of updating the stored value of the operand shall occur between the previous and the next sequence point.
So all we know is that when performing the post increment c will be updated after its value is read but before the next sequence point which is right before printf is called but nothing else. As for the undefined behavior, if we look at section 6.5 paragraph 2 from the draft standard, is says:
Between the previous and next sequence point an object shall have its stored value
modified at most once by the evaluation of an expression. Furthermore, the prior value
shall be read only to determine the value to be stored.
In the printf expression cs prior value is being read in order to evaluate both C++ and C and so we now are in undefined territory.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
In what order does evaluation of post-increment operator happen?
Consider the following snippet(in C):
uint8_t index = 10;
uint8_t arr[20];
arr[index++] = index;
When I compile this with gcc, it sets arr[10] to 10, which means that the postfix increment isn't being applied until after the entire assignment expression. I found this somewhat surprising, as I was expecting the increment to return the original value(10) and then increment to 11, thereby setting arr[10] to 11.
I've seen lots of other posts about increment operators in RValues, but not in LValue expressions.
Thanks.
Some standard language:
6.5 Expressions
1 An expression is a sequence of operators and operands that specifies computation of a
value, or that designates an object or a function, or that generates side effects, or that
performs a combination thereof.
2 Between the previous and next sequence point an object shall have its stored value
modified at most once by the evaluation of an expression.72) Furthermore, the prior value shall be read only to determine the value to be stored.73)
3 The grouping of operators and operands is indicated by the syntax.74) Except as specified later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation of subexpressions and the order in which side effects take place are both unspecified.
Paragraph 2 explicitly renders expressions of the form a[i++] = i undefined; the prior value of i isn't just being read to determine the result of i++. Thus, any result is allowed.
Beyond that, you cannot rely on the side effect of the ++ operator to be applied immediately after the expression is evaluated. For an expression like
a[i++] = j++ * ++k
the only guarantee is that the result of the expression j++ * ++k is assigned to the result of the expression a[i++]; however, each of the subexpressions a[i++], j++, and ++k may be evaluated in any order, and the side effects (assigning to a[i], updating i, updating j, and updating k) may be applied in any order.
The line
arr[index++] = index;
causes undefined behaviour. Read the C standard for more details.
The essence you should know is: You should never read and change a variable in the same statement.
Assignment operation works from right to left, i.e. right part of expression calculated first and then it is assigned to the left part.