You remember incorrectly. The expr4essions of the right are evaluated accoriding to the "normal rules". Only the final result is coerced into the type of the left operand.
----- Original Message ----- From: "Bernd Oppolzer" <[email protected]> To: [email protected] Sent: Sunday, July 21, 2013 11:44:11 AM Subject: Re: Looking for help with an obscure C integer problem BTW: I think I remember from an old book on C programming: "if the target of an assignment is int, all operands on the right side are converted to int - if the target of an assignment is long, all operands on the right side are converted to long" If I remember correctly, this would perfectly explain the behaviour you see (of course, it makes more sense for data types being shorter than the type of the assignment target, but if it's done as written above, you have it for longer types, too). Kind regards Bernd Am 21.07.2013 18:32, schrieb Bernd Oppolzer: > Sorry for jumping late into this thread. > > Why not spend another variable of type long long to do the shift there? > > like > > unsigned long long valueToTest; > unsigned int testWord; > unsigned long long x; > > x = valueToTest >> 32; /* here */ > testWord = (int) x; > > > If now in the expression marked with /* here */ the compiler > does not do the shift as a true 64 bit shift, there is no excuse > and you should report this as a bug. The cast to int is done > in the next statement. > > In the other case there may be some strange language rules > that allow the long long variable to be casted to int before the > shift - I don't know, but why lose time and think much about it? > > Kind regards > > Bernd > > > > > Am 20.07.2013 22:24, schrieb Charles Mills: >> Cross-posted to IBM-MAIN and MVS-OE. >> >> I have the following code fragment in an inline function, compiled by >> the >> IBM XLC compiler as C++: >> >> unsigned long long valueToTest; >> unsigned int testWord; >> testWord = valueToTest >> 32; >> >> It *appears* to me (from somewhat circumstantial evidence in a much more >> complex big picture) when valueToTest has a value of >> 0x0034000000000000 then >> >> - If I compile Opt(0),NoInline then testWord gets the value I expect, >> 0x00340000; but >> - If I compile Opt(2),Inline then testWord gets a value of 0. >> >> Questions: >> >> 1. Does that seem plausible? That the code would work as intended >> Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am >> guessing here) first cast valueToTest to an int of 0, then shift it >> right >> 32, and then assign it to testWord? >> >> 2. What should I code to avoid that? I guess I could shift >> valueToTest first >> (I don't need it again) and then in a separate statement assign it to >> testWord. Is that the "proper" coding technique? >> >> It's fairly involved to test the whole thing so I took the liberty of >> imposing on you folks rather than just trying stuff. Thanks much. >> >> Charles >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
