I'm sure that most of you know that C does not specify which order operands to operators such as + will be evaluated.
E.g. x = exp1 + exp2 might be evaluated by first evaluating exp1, then exp2, then adding the results. However, it might evaluate exp2 first.
How would I make a C assignment that will assign either 1 or 2 to x depending on whether the left or right operand of + is evaluated first?
The problem with writing such an expression is that you can't write to the same variable twice inside it, or the code will invoke undefined behavior, meaning there will be a bug and anything can happen. If a variable is modified inside an expression, that same variable is not allowed to be accessed again within the same expression, unless accesses are separated by so-called sequence points. (C11 6.5/2) See this for details.
So we can't write code such as this:
// BAD CODE, undefined behavior
_Bool first=false;
x = (first?(first=true,exp1):0) + (first?(first=true,exp2):0);
This code invoked undefined behavior because the access to first between difference places of the expression are unsequenced.
However, it is possible to achieve similar code by using functions. Whenever calling a function, there is a sequence point after the evaluation of the arguments, before the function is called. And there is another sequence point before the function returns. So code such as this is possible:
n = expr(1) + expr(2)
This merely has unspecified behavior - since the evaluations of the operands to + is unspecified. But there is no unsequenced access anywhere, meaning the code can't crash etc. We simply can't know or assume what result it will give. Example:
#include <stdio.h>
static int first=0;
int expr (int n)
{
if(first == 0)
{
first = n;
return first;
}
return 0;
}
int main (void)
{
int n;
printf("%d\n", n = expr(1) + expr(2)); // unspecified order of evaluation
first=0;
printf("%d\n", n = expr(1) + expr(2)); // unspecified order of evaluation
return 0;
}
This gave the output 1 1 on my system, but it might as well have given the output 1 2, 2 1 or 2 2. And the next time I execute the program, it may give a different result - we can't assume anything, except that the program will behave deterministically in an undocumented way.
The main reason why this is left unspecified, it to allow different compilers to optimize their expression parsing trees differently depending on the situation. This in turn enables fastest possible execution time and/or compile time.
the simplest code to check for this would look something like this:
#include <stdio.h>
int i;
int inc_i(void)
{
return ++i;
}
int get_i(void)
{
return i;
}
int
main (void)
{
i = 0;
printf("%i\n", get_i() + inc_i());
i = 0;
printf("%i\n", inc_i() + get_i());
}
on my system, this prints:
$ ./test
1
2
which tells me that the left side of the expression is evaluated first. However, while I think that this is an interesting thought experiment, I would not recommend relying on this check to do any meaningful logic in your program - that would be asking for trouble.
You can't. Not reliably. Any time you allow a situation like that to happen in your code the C standard calls it "undefined behavior" and allows the compiler to do whatever it wants. And compilers are notorious, especially in the recent decades, for being completely unpredictable when they encounter undefined behavior. The worst part is that it might even be hard to configure the compiler to warn you that such a situation happened (it can't always know). It is your responsibility to never allow a situation like this to happen.
This might sound crazy but it has a good point. CPUs are different. On some it might make sense to do things in one order. On another that same order will be extremely slow, but doing things in another order is very fast. Maybe the next generation of a CPU will change how instructions are executed and now that third order of operations makes the most sense. Maybe the compiler developers figured out a way to generate much better code by doing things a certain way.
Just because you manage to convince the compiler to generate code that generates a particular order of operations one time doesn't mean that it won't change next time you compile. Maybe the order of the operands doesn't matter at all and they are evaluated in whatever order they happen to be stored in some internal data structure in the compiler and that happens to be a hash table with a hash function that changes on every execution, or maybe the hash function changes next time you update the compiler, or you happen to just add another expression before or after in your code which changes the order, or update another program on your computer that also updates a library that the compiler uses and that library happens to change the order of how some things are stored in a data structure which will change the order of how the compiler generates code.
Note. It is possible to write the expression you want where the order of evaluation wouldn't cause undefined behavior, only be "indeterminately sequenced". In that case the compiler isn't free to do whatever it wants, it is just allowed to evaluate the expressions in whatever order it wants. In most practical situations the result is the same.
