Re: signed/unsigned integer conversion for right shift seems

["Peter T. Breuer" <ptb@inv.it.uc3m.es>]

"Also sprach Tadeus Prastowo:"
> > where it says that conversion MAY NOT or MUST
> > NOT be applied to the arguments of >>.
> 
> Let's assume you could do one or more conversions as you wish. 

I do NOT WISH. I merely want to know what is specified.

> certainly you know you have to follow the spec, don't you?  Now the

No!  I had no idea!  You mean I am not allowed to invent a blue unicorn
as the result or let it kill my granny!  That is such a relief!  Thank
you :-).

> specification of ISO-IEC 1989:1999 says in Section 6.5.7 Paragraph 3:
> "The integer promotions are performed on each of the operands. The

No promotions are performed in this instance as integer promotions are
to change smaller-than-int types to int types, and we start with int
types.

> type of the result is that of the promoted left operand."

We are not interested in the type of the result.

> Now, where do you want to perform your desired conversion? 
> Point A:
> before "The integer promotions are performed on each of the operands"?

No. Integer promotions (i.e., from a type smaller than int to int)
are performed first always, and there are none here, as we start from
ints.

>  Point B: before "The type of the result is that of the promoted left
> operand"? 

That is not a "point" but a statement of the type of the result. It
says it is the same as the type of the PROMOTED (not CONVERTED)  left
operand. That is fine by me. It will be signed int in this case, as
zero promotions are applied to an int, leaving the type as signed int,
and the type of the result therfore as signed int too.

> Point C: after "The type of the result is that of the
> promoted left operand"? 

That is not a "point" either.  Perhaps you are not referring to the
operation of the compiler, and you really mean "where in the text should
we be thinking about"?

If so, there is no single "point" in the text from which deductions are
made, rather a set of statements from which we can make deductions, but
as such your "points" (sorry, no dissing intended) B and C are
irrelevant to the deduction since there has been no observation made
or alleged as to the type of the result.

> Or any other point I have not mentioned?  Or
> at two or more points that I have mentioned?

None of the above are "points" in the operation of the compiler or
the operational semantics of C. As "points" in a specification, A is
the only one that has relevance, as the type of the result (which B, C
treat of ) is not in evidence or contention. But it is vacuuous as
promotions are not performed, the operands being ints to start with.

Apologies for being literal and apparently insisting on "promotion"
meaning "change to integer type from smaller type" but I don't have
an option to understand other than what is explicitly written.  If you
mean "conversion" instead, please say.  

For conversion, the puzzle is why it is NOT done, since the rule

  If one operand has an unsigned type T whose conversion rank is at
  least as high as that of the other operand's type, then the other
  operand is converted to type T.

seems to apply, and would cause the left argument to become unsigned int
to match the right unsigned int, and the shift to become logical, not
arithmetic, which does not happen.

The best I can see is that WHEN and MANY are get-outs in

  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:


> Try it for yourself if you can do one or more conversions at any of

Those are points in a text, not points in the operation of a compiler
(or the runtime), so the sentence above (and below) is not well-formed.

I cannot "try it", therefore.

Or do you mean to try applying deductions at those points?  I refuted
that with "B, C are irrelevant because we do not care about the type of
the result, which makes no difference", and A does not apply (no
promotion is or can be done because the args are ints already).

> the points I have mentioned without breaking the other part of the
> spec.  So, if there is no loophole, a good spec shall not mention any
> other extra thing, shall it?

Eh? "shall not"? I am afraid I cannot parse that last sentence.

Maybe "should not"? Well, the point is that I cannot see a loophole 
allowing conversion NOT to be done EXCEPT possibly the use of WHEN and
MANY in the passage I quoted and none has been pointed to yet.

But the claim that the detailed specs of the >> operator say what's
up seem not to be justified. They don't.  They only relevant thing
is what you quoted as A,B,C above, being para 3 of the "constraints".

There is no exception to the general conversion rule I quoted:

  If one operand has an unsigned type T whose conversion rank is at
  least as high as that of the other operand's type, then the other
  operand is converted to type T.

The best one can do seems to be the WHEN and MANY I commented on above.

Anything else?

Best Regards 

PTB