signed/unsigned integer conversion for right shift seems
Jonathan Wakely
jwakely.gcc@gmail.com
Tue Feb 6 16:45:00 GMT 2018
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
>
More information about the Gcc-help
mailing list