www.embedded.com/story/OEG20020429S0037
The C and C standards do not specify the order of evaluation for function arguments. As I explained in my column last month As Precise As Possible , the C Standard specifies well-defined, portable behavior for many, but not all, language constructs. In some cases, the Standard describes the behavior of a construct as implementation-defined or unspecified. A program with such behavior is valid, but it may yield different results when compiled and executed for different target platforms. The C Standard uses these terms in essentially the same way as the C Standard;
The difference between implementation-defined behavior and unspecified behavior is simply that each compiler must document its implementation-defined behaviors, but not its unspecified behaviors. In other words, implementation-defined behavior is the compilers license to translate a valid construct as it sees fit usually within limits imposed by the Standard, as long as the specifics are documented. Unspecified behavior liberates the compiler from the necessity of documentation.
The upside of this freedom is that it allows each compiler to translate certain constructs into code thats tailored to the target platform. The downside is that it can create portability problems: code that yields expected results on one platform may produce surprisingly different results when compiled and executed on other platforms. This month, Ill examine one specific example of unspecified behavior.
The call evaluates the arguments from left to right, and performs the post-increment on the first argument, n, before evaluating the second argument. Thus, the first argument evaluates to zero, the second argument evaluates to one, and the function call produces the following output: i 0;
For example, n is an expression that both yields a value and has a side effect. The value of the expression is the value of n before its incremented. A function call has evaluated the argument once it has copied n into the parameter storage area for the call on the stack or in a register. The entire argument expression, including the side effect, need not be completely executed at that point. The function call can complete the side effect before it evaluates the next argument, or it can delay completing the side effect until just before jumping to the function. Both compilers for the ARM7 apparently evaluate function call arguments from left to right, but we cant tell yet whether the Pentium compilers evaluate function arguments from left to right or from right to left. Lets see what happens when we compile a different function call: n 0;
The call evaluates the right argument first, which increments n, and then it uses the incremented value for the left argument, too. The compiler could do the pre-increment of the second operand before it does anything else. So you still cant tell from the output exactly how the compiler evaluates the function call arguments.
Since the order of evaluation for function arguments is unspecified, a compiler can evaluate the arguments to a call in any order, as long as it evaluates all the arguments before jumping to the function. In theory, a compiler could use even a random number generator to determine the order of evaluation for each call. In practice, most compilers seem to use either left-to-right or right-to-left for all calls. The four Pentium compilers I tested evaluate function arguments from right to left. I was surprised to find that the two compilers for the ARM7 varied the order of evaluation from call to call.
I dont believe this curious change in the argument evaluation order is a consequence of the ARM7 instruction set. I looked at the code that each compiler generated and its remarkably different considering the similarity of the result. Staying away All other things being equal, portable code is better than non-portable code. Function calls that depend on the order of argument evaluation are non-portable, and you should avoid them. How do you know if youve written a call with an evaluation order dependency?
This warning says the call has undefined behavior, not just unspecified behavior. A program exhibiting undefined behavior is not just a non-portable program-its an erroneous program. This brings us to a subtle point: although the order of evaluation for function arguments is unspecified, a program that pushes too far into unspecified territory can produce undefined behavior. Next time, Ill explain what a sequence point is and how it elevates this particular unspecified behavior into an undefined behavior. Dan Saks is the president of Saks & Associates, a C/C training and consulting company.
PCBpro-Easiest Site to Quote/Order Circuit Boards Free quotes for circuit boards in seconds with no sign up required. Easy order process makes it easy to complete your circuit board needs. Discover the MIPS benefits that enable the success of Cisco, HP, Sony other equipment: performance, architecture, instruction set, devices, cores, compilers operating systems. Free webinar presented by Tom Riordan,a MIPS architecture pioneer.
|
http://csua.com/feed/