Re: signed/unsigned integer conversion for right shift seems

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

"Also sprach Jonathan Wakely:"
> >> Are you trolling or just stubborn and unable to accept the help you asked for?
> >
> > I would be grateful if you desisted from ad hominen attacks.
> 
> Stop acting like an idiot then.

See above.  I and doubtless the world would appreciate it if you
refrained.  

> > WHAT, specifically, do you see in 6.5.7 that allows the conversion
> > specified by the general rule of conversions
> >
> >  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.
> >
> > NOT to be applied?
> 
> Because it doesn't say they are applied. As I pointed out in

An interesting new theory, if late to the party.  You now say that the
phrase "the usual arithmetic conversions" (6.3.1.8) must be present in
the subsection relating to the operator?

Ingenious, and I'll look at that as a possibility.  Let's test.
According to the index, the phrase occurs in

   usual arithmetic conversions, 6.3.1.8 [defn], 6.5.5, 6.5.6,
   6.5.8, 6.5.9, 6.5.10, 6.5.11, 6.5.12, 6.5.15

6.5.5 = multiplicative ops (* / %)
6.5.6 = additive ops (+ -)
6.5.8 = order relations (> < <= >=)
6.5.9 = equals relns
6.5.10= bitwise &
6.5.11= bitwise ^
6.5.12= bitwise |
6.5.15= ternery op ?:

That looks plausible. 6.5.7 (>> and <<) is about all that's missing.
The rubric usually goes

  Semantics
  3 The usual arithmetic conversions are performed on the operands.

and it is not present in 6.5.7, which instead has

  Semantics
  3 The integer promotions are performed on each of the operands.

We (I!) have throughout the thread noted that there are no promotions to
be done here as both args are already int.

The possible argument put forward by someone that promotions are "a
part" of conversions and no promotions implies no conversions, I did
not find convincing (it's possible to be a not-there part of a thing
with extent, like windows in a room; a room does not _have_ to have
windows).

So this looks the strongest argument so far.  Well done.

> https://gcc.gnu.org/ml/gcc-help/2018-02/msg00031.html the other
> operators *do* say the conversions are applied.

Indeed. Strong argument, comparing the other op specs in deatil.

> >    The arguments of the following arithmetic operators undergo implicit
> >    conversions for the purpose of obtaining the common real type, which
> >    is the type in which the calculation is performed:
> >    binary arithmetic *, /, %, +, -
> >    relational operators <, >, <=, >=, ==, !=
> >    binary bitwise arithmetic &, ^, |,
> >    the conditional operator ?:
> >
> > That's all. No ">>" operator there, so no maybe. Your claim is false
> > there.
> 
> Exactly, the shift operators are not listed there, because the
> conversions are not done for the shift operators.

That doesn't work as logic - it's circumstantial and unsafe as a mode of
reasoning.  The += is also an (impure) arithmetic operator and it should
follow the same conversion rule as +, which is in your/that list.

   A compound assignment of the form E1 op = E2 differs from the simple
   assignment expression E1 = E1 [+|-] (E2) only in that the lvalue E1 is
   evaluated only once.

According to that it does borrow the semantics of + which explicitly has
the "usual arithmetic conversions" phrase, yet the phrase doesn't appear
in the text for += and the operator is not listed in the set you gave.
So according to your reasoning it should NOT have the "usual arithmetic
conversions", yet it does.

[There looks a semantic morass here, since the two imaginary appearances
of the lhs might get two different types through the rules.  It's not as
simple as foo=foo op bar, and what it boils down to exactly depends on
the lhs and the rhs, especially in case of explicit side-effects in
those.]

> >> http://en.cppreference.com/w/c/language/operator_arithmetic#Shift_operators
> >
> > That's a different place ... it seems to say what we have already
> > quoted in the standard.
> >
> >   First, integer promotions are performed, individually, on each operand
> >   (Note: this is unlike other binary arithmetic operators, which all
> >   perform usual arithmetic conversions). The type of the result is the
> >   type of lhs after promotion.
> >
> > No integer promotions can be performed, since the args are already ints.
> 
> Read the parenthesis! It explicitly says that for these operators,
> unlike most others, arithmetic conversions are not performed!

It doesn't say so explicitly (but you have - explicitly would be saying,
as you did above, "the usual arithmetic conversions are not performed").

You are saying it is not explicit but it is implicit?

Could be ...  could be not.  Hard to say.  So it is not. Implicit means
logically deducible, "implied though not directly expressed", as the
dictionary has it. I don't see it as a _necessary_ consequence, just
a possible one.

To explain, there's that finesse over whether promotions are supposed to
be a part of conversion (see somebody else in this thread, maybe even
you for all I know right now!) or not to consider, plus whether they're
lax or not in differentiating promotions from conversions.  One could
plausibly read this text as saying that promotions are performed in this
case whereas they are omitted in other cases, but in all or some or many
cases, including this, one goes on to perform the rest of the
conversions apart from the promotions.

In my opinion, however, this is corroborating evidence in favor.

But its's still just circumstantial stuff.  One has to watch out for
circumstantial evidence and not jump to conclusions (engineers make that
logical mistake, as a general rule, for lack of abstract thinking
pathways).

> > There is no "Second".
> >
> > If they meant to say
> >
> >   "Second: NO sign conversions MAY be performed, so what you get after
> >   (possibly vacuuous) int promotion you are stuck with, "
> >
> > then they forgot to say it.
> 
> You are an idiot.

Desist from insults and attacks.  I have written an appropriate sentence
that would explicitly prohibit arithmetic conversion for >> in any
conforming compiler implementation.  Why haven't they?

Check out the "Dunning-Krueger effect" on Wikipedia.

To me, the spec looks pretty much collated from older bits of spec,
updated imperfectly. Shrug. What isn't?

I'll see if I can talk to somebody on the WG.

Regards

PTB