Thread: How?

Hello all,

When I run this code:

Code:

#include <stdio.h>

void main()
{
    int k = 35 ;
    printf ( "\n%d %d %d", k == 35, k = 50, k > 40 ) ;
}

The output is:

Code:

0 50 0

I can't get how the compiler dealt with this...

The only explanation is: The code is executed from right to left. So firstly, k is equal to 35. k > 40 is false. New value is assigned to k. k == 35 is false.

Any help?
Thanks in advance.

Question 3.7
http://c-faq.com/ansi/maindecl.html

Yep, that's as good an explaination as any.

Originally Posted by hk_mp5kpdw

The order of evaluation of the arguments to a function call is unspecified.

Understood... but that doesn't explain his results...

Originally Posted by MK27

Sure it does -- argument #2 is an assignment.

I think you misunderstood what I was saying...

Simply telling hime that it's "unspecified" or "undefined" does not explain the results. The next compiler he tries that on may give different results... hense it is important to understand that it is undefined --compiler specific-- behavior. It does tell him why he shouldn't go that, but it doesn't explain the result...

Noting that it's probably evaluating from right to left does offer something of an explaination.

It's the difference between answering: "Don't do it" and "This may be why it happens".

Thanks guys for your responses. And thanks Bayint Naung and CommonTater.

Originally Posted by nonoob

Yup. Looks like this compiler evaluated from right to left... same order as how the parameters are pushed to the stack. Makes sense. But as has been mentioned - order of evaluation is not specified in the standard. Other implementations may exist that go left-to-right, or any order.

Indeed. I just tried this out on the MSVC 2008 compiler -- it gave:

Code:

int k = 35 ;
printf ( "\n%d %d %d", k == 35, k = 50, k > 40 ) ;
output: 0 50 1

Code:

int k = 35 ;
printf ( "\n%d %d %d", k == 35, k == 40, k = 40 ) ;
output:  0 1 40

So it did them in a different order each time (but both times did the assignment first). So... not only will any code that relies on this be non-portable, it might even break when only using one compiler.

Originally Posted by nonoob

It sure would have been nice had the fine folks who wrote the standard included all of these type ambiguities and nailed them down. My guess is that they were forgetful and/or lazy, and that's why they were left out. Now it's officially "undefined" but it was never designed or meant to be a non-deterministic aspect of the compiler. Something like this evaluation order could have just as easily been specified since day1 and there would never be any more confusion. Now we're stuck with accepting undefined behaviour because, hey, the compiler writers "meant to do that". Ha!

Indeed. Made worse by the distinction between "unspecified" and "implementation defined". "Unspecified" seems to mean that it doesn't need to be documented per-implementation, as well as not being in the standard. If the compiler docs said "we do it this way" it wouldn't be so bad. Still would need some care in portable code, but at least you could be sure you knew what would happen, and that the compiler wouldn't change without warning.

I hate unpredictable/undefined/unspecified/.... and I note that some compilers try to lock down and document unspecified behaviour (probably from customer demand). I wish all compilers would document what they do in 'unspecified' cases. Even if it's to document that it does something crazy and unreliable. Then you can decide whether or not you want to use said feature, instead of really not being able to.

Thanks, smokeyangel, for your understanding. I expected people to immediately yell at me for bad mouthing the geniuses that are compiler writers and standards committee members. As if they're any smarter than many real programmers who write code for a living like many on this board. They ain't.

It's hard to believe one compiler will do the evaluation in either order.

Heh. Good point about "tease students". Although I did find a discussion about sequence points fascinating. Funny how these things are irrelevant if you write reasonable, commercial-grade code for a living. And yet sadistic teachers and "clever" students find ways to create problems where there were none.