"Also sprach Tadeus Prastowo:"
> > ...................................... The type of E1 is UNSIGNED INT
> > by the type promotion/conversion rules I quoted.
>
> To quote the same document's Section 6.5.7 Paragraph 3: The integer
> promotions are performed on each of the operands. The type of the
> result is that of the promoted left operand. End quote.
Yes, but no promotions are performed (I ceased reading the sentence at
that point - hit me if I do wrong). I quote
Integer Promotions
Integer types smaller than int are promoted when an operation is
^^^^^^^^^^^^^^^^
performed on them.
The types are not "smaller than int" here. (signed int and unsigned
int respectively in x >> y). No promotions.
I'll read on .. hmm. I don't actually care what the result type is
(signed or unsigned - definitely int) is in this instance, as I don't
use it except to print its bits. So I don't see the final sentence
as relevant.
That promotions (of which I contend there are none; penultimate
sentence) are performed on each and all of the operands does not
disturb me. None seem to have been performed, going by the result, so I
do not see that sentence as relevant either.
> And to quote Section 6.3.1.1 Paragraph 2: [...] If an int can
> represent all values of the original type, the value is converted to
> an int; otherwise, it is converted to an unsigned int. These are
> called the integer promotions. All other types are unchanged by the
> integer promotions. End quote.
That is a quote for a promotion, of which none are performed. Let me
fill out the quote (my caps)
Integer types SMALLER THAN INT are promoted when an operation is
performed on them. If all values of the original type can be
represented as an int, the value of the smaller type is converted to
an int; otherwise, it is converted to an unsigned int. Integer
promotions are applied as part of the usual arithmetic conversions to
certain argument expressions; operands of the unary +, -, and ~
operators; and OPERANDS OF THE SHIFT OPERATORS.
Not smaller than int, so no promotions.
(I'm quoting something at CMU, rather than wherever you are quoting
from,
https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules
simply because I have to quote something and that's what google is
showing me)
We should be looking at the rules for conversions, not promotions.
> So, E1 has type signed int, hasn't it?
No promotion is applied. I get what you saying, however, which is that
zero promotions is a promotion (!), so we should end up with int
from this nonexistent promotion of the left argument. I agree as far
as that goes (see end of para), we should, but not by virtue of a
promotion, but by the absence of a promotion. Everything is hunky dory
as we are supposed to promote to ints (or unsigned ints) for arithmetic
and we have that already. I contend we are then supposed additionally
to CONVERT, not promote, by the "usual arithmetic conversion" rules.
These rules include integer promotions, integer conversion rank, and
the USUAL ARITHMETIC CONVERSIONS.
Can you look at that?
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:
The best explanation I have seen so far is that there is no WHEN
here, because the MANY does not include >>.
I have not been able to repy to what has seemed to me to be the only
valid excuse - because of the deluge. Apologies to whoever it is.
(I think I noticed the reasoning was a bit wonky there too, but maybe
I was intoxicated when reading it).
Regards
PTB
