Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
06/23/07 00:18
Read: times


 
#141171 - The real reason???
Responding to: ???'s previous message
Jeff said:
Some operators are assumed to be associative and commutative (^ is one of them). The compiler is permitted to evaluate in any order it sees fit, which if for whatever reason it decided not to evaluate right to left would give a different result than what you expect.

The compiler will, or should, generate a warning message that the result is undefined, though most will evaluate the operations in the order you'd expect.

x^=y^=x^=y;	// Don't try this at home!!!
Well, darn. That little trick sure looked innocent enough when I posted it. I'm also learning a lot more from this "quiz" than I expected to.

After doing a little research, I agree with Jeff that the code is not proper C. However, I don't agree that the compiler is free to apply the operators in any order. First of all, the operator in question is ^= and not plain ^. The table in section 2.12 of K&R gives the associativity of ^= (and all the other assignment operators, too) as "right to left". I'm pretty sure that means that the ^= operations in the example are guaranteed to be executed from right to left.

So what's the problem with the example?

As far as I can tell (based on the closing paragraphs of K&R, section 12), it seems that the real problem is that the compiler is free to perform the actual variable assignments in any order and at any time it wants. So, while the value of the rightmost instance of "x^=y" is unquestionably x^y, the language doesn't specify whether that value will be or won't be actually assigned to x prior to the execution of the remaining two operators. Similarly, after the execution of the middle operator, there is no guarantee one way or the other if the result will be assigned to y before the execution of the leftmost operator. Given that, it's pretty clear that the example is ambiguous.

In trying to figure this out, I found that we are not breaking any new ground here. A discussion in comp.lang.c of the exact same problem quickly degenerated into a war of words (big surprise) because the poor guy who originally posted it hadn't read the newsgroup's FAQ. And it turns out that the comp.lang.c FAQ does explain it (see question 3.3b), albeit in terms more geared to students of the actual C standard than to us mere mortals who can barely understand K&R.

Anyway, I learned something today (there's always that risk!), and I apologize if I confused anybody with the example.

-- Russ


List of 36 messages in thread
TopicAuthorDate
Mini quiz for Friday            01/01/70 00:00      
   a classic            01/01/70 00:00      
   Non kosher C            01/01/70 00:00      
      Please Explain            01/01/70 00:00      
         The reason            01/01/70 00:00      
            The real reason???            01/01/70 00:00      
               welcome to the club            01/01/70 00:00      
            Worse than "implementation dependent"            01/01/70 00:00      
               Can you clarify this point?            01/01/70 00:00      
                  splint gives a (very) detailed warning:            01/01/70 00:00      
                     Interesting ...            01/01/70 00:00      
                        Sequence point            01/01/70 00:00      
   Lesson complete            01/01/70 00:00      
      The weird part            01/01/70 00:00      
      There's a fine line            01/01/70 00:00      
         Problem            01/01/70 00:00      
            operator precedence            01/01/70 00:00      
               I second the motion            01/01/70 00:00      
                  As I said            01/01/70 00:00      
                     re: As I said            01/01/70 00:00      
                        Productivity?            01/01/70 00:00      
                           wrong comment            01/01/70 00:00      
                           re: Productivity            01/01/70 00:00      
                        that's IT            01/01/70 00:00      
                           Then again ...            01/01/70 00:00      
                              OK, is this better ?            01/01/70 00:00      
                                 12 year olds are smarter            01/01/70 00:00      
                                    Sorry but            01/01/70 00:00      
                                       Order of operations            01/01/70 00:00      
                                       I know            01/01/70 00:00      
                                    How about ...            01/01/70 00:00      
                                       Wrong?            01/01/70 00:00      
                                          point proven            01/01/70 00:00      
         Real Work vs. Fooling Around            01/01/70 00:00      
            I got caught out recently            01/01/70 00:00      
               re: I got caught out recently            01/01/70 00:00      

Back to Subject List