signed/unsigned integer conversion for right shift seems
Peter T. Breuer
ptb@inv.it.uc3m.es
Tue Feb 6 16:42:00 GMT 2018
"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
More information about the Gcc-help
mailing list