4

I am in the process of writing a non-destructive conversion routine in C and I have just realized that (at least in Visual C++) functions are resolved in the reverse order.

So:

main()
{
char* psString[] = { "Hello", "World", "World2", "World3" };

printf("%s - %s - %s - %s\n", 
    H2A_N(psString[0]), 
    H2A_N(psString[1]), 
    H2A_N(psString[2]), 
    H2A_0(psString[3]));

return 1;  
};

My code is not re-entrant and runs only in a single thread so I was going to use a static array of characters to store the results.

My plan was to have a function H2A_0 which wrote the output to the start of the buffer and left behind the next address for subsequent calls to H2A_N.

I do realize there are some shortcomings to this approach but I have to apply this conversion routine to a lot of existing code so the simpler the better (I don't want to mess with releasing memory).

My question is:

  1. Is it part of the C standard to resolve functions (when they are passed as arguments to other functions) in reverse order.
  2. Is there a better way to do this?
  • Try to copy the strings with `strdup()`. The standard return value from `main()` is supposed to be `0`. – ott-- Jun 01 '13 at 21:26
  • 1
    c.f. http://stackoverflow.com/questions/621542/compilers-and-argument-order-of-evaluation-in-c – imallett Jun 01 '13 at 21:27
  • 1
    @ott--: I'm not sure `strdup()` is available on Windows. At least, it's not part of the C standard (it's a POSIX function, like `fork()`). – Dietrich Epp Jun 01 '13 at 22:34

3 Answers3

7

There is no defined order of evaluation of parameters. The compiler is free to decide which order to evaluate them, as it pleases.

The latest version of the standard, C11, says so like this, §6.5.2.2/10:

There is a sequence point after the evaluations of the function designator and the actual arguments but before the actual call. Every evaluation in the calling function (including other function calls) that is not otherwise specifically sequenced before or after the execution of the body of the called function is indeterminately sequenced with respect to the execution of the called function.

If you wish to force a specific order of evaluation you'll need to pull the expressions out of the function call, and save them away to local variables.

int param1 = foo(...);
int param2 = bar(...);
DoSomething(param1, param2);

Is there a better way to do this?

Very probably. Having functions return values and also apply side effects to fixed length statically allocated buffers is not generally considered best practise. However, I would not wish to tell you how to solve your problem because I don't know enough about the problem.

David Heffernan
  • 572,264
  • 40
  • 974
  • 1,389
1

Is it part of the C standard to resolve functions (when they are passed as arguments to other functions) in reverse order.

Functions argument are evaluated as an expression; and as such,it's implementation-defined,like in x = f() + g(). If f() will be called before to g() depends to compiler to compiler,check out sequence point.

Some compilers,like icc can given a warning about this:

remark #981: operands are evaluated in unspecified order

The Mask
  • 15,697
  • 36
  • 104
  • 172
-2

Should have checked first. There is no defined order of resolution. Most compilers appear to resolve right to left.