-3

I had an interview last week and the interviewer asked me this operator precedence issue. Please somebody help me in understanding the logic for this program. I am working on Ubuntu(linux)

int main()
{
    int var = 90;
    if(var  += var == ++var ==8)
        printf("val of var is %d \n",var);
}

The output of this program is 91.

How is multiple == in the loop evaluated (associativity is left to right)???

Interestingly if I tweak the code as

int main()
{
    int var = 90;
    if(var  += var == ++var)
        printf("val of var is %d \n",var);
}

Then the output comes as 92.

Is this behavior a compiler dependent thing???

Anshul
  • 1,416
  • 1
  • 16
  • 42
  • 1
    As a side-note, I can show you a hundred really good C programmers who couldn't answer this question without looking at the operator precedence table. Bad interview question. – thiton Feb 12 '13 at 10:50
  • I'm with @thiton: this is a lame interview question. You probably shouldn't work there. – John Zwinck Feb 12 '13 at 10:50
  • 1
    This isn't an operator precedence question -- there are two modifications to `var` with no intervening sequence point. This code's just broken. – David Schwartz Feb 12 '13 at 10:51
  • but how did multiple == gets evaluated here in if loop??? – Anshul Feb 12 '13 at 10:53
  • 2
    The correct answer is to rewrite the code and force the original programmer to work in COBOL. – pmg Feb 12 '13 at 10:54
  • @Ansh you expect a reasonable answer. Don't do that - it's UB. One cannot possibly make sense of this mess. –  Feb 12 '13 at 10:55
  • "*Is this behavior a compiler dependent thing???*" It could be compiler dependent. It could be platform dependent. It could be temperature dependent. It could even be dependent on the phase of the moon. It's called undefined behavior because it's undefined. The compiler is permitted to rely on the fact that you will never do this. – David Schwartz Feb 12 '13 at 10:56
  • No matter what the precedence is, the `==` comparisons will yield false (`0`) in any case, and are therefor meaningless and only there to distract you. – JimmyB Feb 12 '13 at 10:57
  • 1
    Why are you talking about loops? There are no loops in this code. – unwind Feb 12 '13 at 10:57
  • @HannoBinder The term undefined behaviour describes "features", if you may call them that, for which C has no requirements. Keep "no requirements" in mind, and read the message you wrote minutes ago. – autistic Feb 12 '13 at 11:04
  • Why do people keep argumenting by the "C Standard" over and over again? - Given that there are a host of different compilers, each implementing its own variant of the standard, the only valid answer here is "it depends on the compiler". No compiler will output "undefined" code; it will either compile it in a deterministic way or it will reject it as syntactically incorrect. Period. – JimmyB Feb 12 '13 at 11:15
  • @HannoBinder "Given that there are a host of different compilers, each implementing its own variant of the standard, ..." That's very far from "given": compilers that implement their "own variant of the standard" necessarily implement a different programming language. It may look like C and in many cases even behave like C, but it is not considered C unless it is fully compliant with the standard. – Sergey Kalinichenko Feb 12 '13 at 11:24
  • @HannoBinder First of all, the difference between undefined and unspecified behavior is that the latter is deterministic, while the former is not. A compiler may very well produce different results each time UB is executed, in case it makes different optimization decisions, or in case there are multiple threads, multiple CPU cores etc etc. As for "undefined code", GCC used to launch a computer game every time a program invoked undefined behavior. – Lundin Feb 12 '13 at 12:28
  • @HannoBinder: Nothing requires a compiler to emit deterministic code in the face of UB and many compilers don't. I encountered a program that worked sometimes and not other times earlier today due to unintentional UB. A boolean variable wasn't initialized when it was supposed to be and on some runs of the very same program, it was true and on others false. – David Schwartz Feb 12 '13 at 13:06
  • @dasblinkenlight: I have yet to find a C compiler that, as a reference implementation, is fully compliant to 'the' standard. – JimmyB Feb 12 '13 at 14:34
  • @David Schwartz: This is not really related to the compiler, which probably generated deterministic and correct code from the source code it was given. Building code which creates a deterministic result from non-deterministic input _data_ is not the compiler's duty but the programmer's. – JimmyB Feb 12 '13 at 14:53
  • @HannoBinder: The program was running a fixed test suite. The test suite sometimes failed and sometimes passed. It's entirely possible (though I admit, not very likely) that the code was literally non-deterministic. For example, if it depended on which of two disk reads completed first, that could depend on turbulent shear airflow inside the hard drive. There is no requirement that the compiler ensure the code does the right thing, so it can depend on external factors -- even quantum effects. (Though more likely, it was quasi-determinstic. Say, dependent on the PID or something like that.) – David Schwartz Feb 12 '13 at 14:55
  • @Lundin: "[a] compiler may very well produce different results each time UB is executed" - Of course 'the' standard 'permits' it to do so, by not specifying what _must_ be done. However, a compiler which generates semantically different output code from identical source code sections without complaining should be considered broken, irrespective of whether the inconsistency appeared in 'specified' constructs or not. - As I said above: Being encountered at run-time only, concurrency, threading and the like are not relevant to the compiler and cannot have impact on the output of the _compiler_. – JimmyB Feb 12 '13 at 15:09
  • @David Schwartz: Yes, it most probably was just a read on un-initialized memory, which was used before to store some other data which in turn may have varied from test run to test run. – JimmyB Feb 12 '13 at 15:15

2 Answers2

3

The right answer would be that this is undefined behavior due to lack of sequence point between expressions with side effects.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
-1

Lets do it step by step

  1. ++var

  2. 91 == 91 (+=var == ++var)

  3. 1 == 8 (+=var == 8)

  4. var = 91 + 0

Sam
  • 2,352
  • 4
  • 32
  • 45