On 6 February 2018 at 16:42, Peter T. Breuer <ptb@xxxxxxxxxxxxxx> wrote: > "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 :-(. You've already been told that 6.5.7 says "The integer promotions are performed on each of the operands. " and says nothing about conversions. > 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. The specification of each operator tells you if it's applied. 6.5.7 doesn't say they are, so they aren't. > 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. Then you're not paying attention. > 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 >
