signed/unsigned integer conversion for right shift seems

[Jonathan Wakely]

On 6 February 2018 at 16:42, Peter T. Breuer <ptb@inv.it.uc3m.es> 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
>