Question

What tasks, features, executions vary with compiler? I know this code is compiler-dependent-

#include <stdio.h>
#define PRODUCT(x)(x*x)
int main()
{
int i=3,j,k;
j=PRODUCT(i++);
k=PRODUCT(++i);
printf("\n%d %d",j,k);
}

Following gives garbage in some, while fixed values in others-

#include <stdio.h>
int main()
{
int i=5,j=10;
printf("%d,%d");
}

So order of execution vary with compilers.
Are such ambiguous programs eligible to be asked in exams?

Answer 1

If you want the full list, you’ll need to look to the standard document. In the C standard there are two types of ‘compiler-dependent’ issues defined:

• Implementation-defined behavior: The behavior may vary from compiler to compiler, but the compiler must provide some sort of consistent behavior, and must document this behavior. An example, straight from the standard: “An example of implementation-defined behavior is the propagation of the high-order bit when a signed integer is shifted right.”. In other words, the result of -1 >> 1 may vary between compilers, but the compiler has to be consistent about it.
• Undefined behavior: All bets are off. The moment you hit undefined behavior, anything – and I do mean anything can happen. Your code is a good example of this – you modify a single variable twice without an intervening sequence point (in violation of ISO/IEC 9899:1999 (E) §6.5’s constraint). And in the second one, you are missing parameters (undefined behavior per §7.19.6.1/2). According to a strict reading of the standard, it is perfectly justified for the compiler to summon demons through your nose in this case.

You also need to watch out for constraint violations. Often the standard specifies things like “[main] shall be defined with a return type of int […]” (§5.1.2.2.1/1). This is equivalent to, “If main is declared with a return type other than int, the program’s behavior is undefined.” (see §4.2, where the standard explicitly endorses this interpretation)

You should not be asked these questions on an exam; if you are, you should simply state that the behavior of the program is undefined (or implementation-defined). Note that some implementation-defined behavior has limits – eg, the value of sizeof(int) is implementation defined, but you know that sizeof(int) >= sizeof(short) && sizeof(int) <= sizeof(long) – so just having any implementation-defined behavior doesn’t mean you can’t say anything about what the program does.