"Also sprach Jonathan Wakely:" > > The usual arithmetic conversions are rules that provide a mechanism > > to yield a common type when both operands of a binary operator are > > ^^^^^^^^^^^^^^ > > balanced to a common type ... > > > > Ergo, one was unsigned, so they should both have been. > > No, because the operands of bitshift operators aren't balanced to a common type. Where does it say that? Your word isn't quite enough for me :-(. By the way, this is the conclusion I have come as being the most likely explanation by dint of certain weaselly words in the definition of when the CONVERSION rule should be applied (my caps): The usual arithmetic conversions are rules that provide a mechanism to yield a common type WHEN both operands of a binary operator are balanced to a common type or the second and third operands of the conditional operator ( ? : ) are balanced to a common type. Conversions involve two operands of different types, and one or both operands may be converted. MANY operators that accept arithmetic operands perform conversions using the usual arithmetic conversions. After integer promotions are performed on both operands, the following rules are applied to the promoted operands: It doesn't require the rules to be applied, it only talks about WHEN they are applied. It leaves it open as to to which operators that the conversion rules are to be appled to. What is the complement of the MANY, precisely? I am willing to accept that it includes ">>". Any more? "<<", I suppose, but the result would be insensitive to the change .. anything else? The first versus second/third arguments of ?:. And the arguments of the comma operator can be left to differ in type too, not that it makes any difference. > You asked for clarification and have got your answer, but seem > determined to stick to your original interpretation. No, I conclude whatever is logically required, and point out false aka mistaken logic where it is attempted. I don't mind what answer you or I get, so long as it is reasoned correctly, or at least convincingly. I haven't yet seen a constructive argument towards what I see as the probable out - that >> is just one of the 3 or 4 exceptions. Hmm ... would x/y show an effect like that? Yes. signed/unsigned is signed, with no conversion to a joint "unsigned" type taking place as per the conversion rule: If the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type is converted to the type of the operand with unsigned integer type. SO / and likely % (yes?) are likely other exceptions. That's >> << (?) / % (?) , ?: where no conversion after promotion occurs. The others are + - * and for them it doesn't matter as 2s complement gives the same result whatever. Is there somewhere in the standard where it SAYS this? Regards and thanks PTB