1

testing some code when studying C language, 

#include <stdio.h>
#include <math.h>
#define hypotenusa(x, y)  sqrt((x) * (x) + (y) * (y))

int main(void) {
    int a, x;
    x = 2;
    a = hypotenusa(++x, ++x);
    printf("%d\n", a);
}

And I am getting the answer

  • 6 in one program(dosbox gcc compiler)
  • 7 in codelight gcc compiler and
  • 8 on codeChef online compiler

can anyone explain this behaviour? my logic says it should be 6 (sqrt(42)) but...

chqrlie
  • 131,814
  • 10
  • 121
  • 189
mikeN
  • 29
  • 4

3 Answers3

5

It's undefined behaviour.

After the macro replacement

a = hypotenusa(++x, ++x);

becomes:

a = sqrt((++x) * (++x) + (++x) * (++x));

As you can see x is modified multiple times without any intervening sequence point(s). See What Every C Programmer Should Know About Undefined Behavior.

P.P
  • 117,907
  • 20
  • 175
  • 238
  • 1
    It worth noting, that converting it to a function call won't solve the problem, as the order of operands evaluation is not defined too.. – Eugene Sh. Dec 28 '16 at 16:52
2

hypotenusa(++x, ++x) is undefined behavior.
It is up to the compiler which of the parameters gets incremented (and pushed) first - after the macro expansion, there are a total of four instances, and the sequence is not defined.

You should never increment the same variable multiple times in the same statement, to avoid this kind of issues. Using a variable twice in a macro can hide this error and make it really nasty.

Aganju
  • 6,295
  • 1
  • 12
  • 23
  • `hypotenusa` is a macro, not a function call, and there is nothing wrong with incrementing a variable during a function call, so long as you increment it ONLY ONCE. Trouble happens when you increment the same variable multiple times. – abelenky Dec 28 '16 at 16:26
  • @abelenky , the macro expands to a function call. But I have adjusted the text to be more precise. – Aganju Dec 28 '16 at 16:30
  • Could you clarify the first paragraph. It suggest that the undefined behavior will result in one of the two possible outcomes, which is not the case. – 2501 Dec 28 '16 at 16:50
2

The behavior of your macro is undefined, meaning any result is possible.

Chapter and verse

6.5 Expressions
...
2     If a side effect on a scalar object is unsequenced relative to either a different side effect
      on the same scalar object or a value computation using the value of the same scalar object,
      the behavior is undefined. If there are multiple allowable orderings of the subexpressions
      of an expression, the behavior is undefined if such an unsequenced side effect occurs in any
      of the orderings.84)
84) This paragraph renders undefined statement expressions such as
    i = ++i + 1;
    a[i++] = i;
      while allowing
    i = i + 1;
    a[i] = i;

Basically, if you modify the value of an object more than once in an expression, or both modify an object and use its value in a computation in an expression, the result will not be well-defined unless there is a sequence point in between those operations. With a few exceptions, C does not force left-to-right evaluation of expressions or function parameter evaluations, nor does it mandate that the side effect of ++ or -- be applied immediately after evaluation. Thus, the result of an expression like x++ * x++ will vary from platform to platform, program to program, or even potentially from run to run (although I've never seen that in practice).

For example, given the expression y = x++ * x++, the following evaluation sequence is possible:

t0 <- x        // right hand x++, t0 == 2
t1 <- x        // left hand x++, t1 == 2
y <- t0 * t1   // y = 2 * 2 == 4
x <- x + 1     // x == 3
x <- x + 1     // x == 4

which doesn't give you the result you expect if you assume left-to-right evaluation.

John Bode
  • 119,563
  • 19
  • 122
  • 198