signed/unsigned integer conversion for right shift seems
Peter T. Breuer
ptb@inv.it.uc3m.es
Tue Feb 6 18:23:00 GMT 2018
"Also sprach Jonathan Wakely:"
> >> The specification of each operator tells you if it's applied. 6.5.7
> >> doesn't say they are, so they aren't.
(attempt to apply no say = must not ignored for the purposes of a
communicative interaction with the humanZ here ...)
> > I don't have a "specification of each operator" to look at ... probably
> > it doesn't junp out from google for me as easily as other stuff does.
>
> See the C standard.
Where specifically? I am now looking at the draft standard for
ISO-whatever at
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
I am working through the 194 instances of the word "arithmetic"
and the closest I have seen to a statement on the subject is in footnote
48 under paragraph 6.3.13 (I think .. can't see all the page) which
says:
The integer PROMOTIONS are applied only: as part of the usual
arithmetic CONVERSIONS, to certain argument expressions, to the
operands of the unary +, -, and ~ operators, and to both operands of
the shift operators, as specified by their respective subclauses.
which says (wrongly IMO) that promotions are some part of conversions,
but we know what they mean.
At any rate the implication is that CONVERSIONS, comprising as per their
language a carrier for PROMOTIONS, ARE applied to BOTH operands of THE
SHIFT OPERATORS, which seems to me to imply that both operands must be
cast to the same type, otherwise to what type are they to be converted?
Perhaps it has an exception in the "their respective subclauses"
get-out. Where is that ...
> > I wonder if I could I ask you to quote the ">>" specification for my
> 6.5.7 in C99 or C11
Hmm ... [goes looks in what he has] ... yes, that is semantics for
bitwise shifts:
The integer promotions are performed on each of the operands.
None are performed in this case, but there's that text from footnote 48
that I quoted above which says that promotions are part of conversions,
so no promotions implies no conversions.
That is, unless they mean that "as part" in the footnote may apply to a
nonexistent part, in which case conversions may still happen because
they would contain the nonexistent part consisting of the nonexisting
promotion that was not done - I hope I am being clear.
(for completeness, the rest of the para ...)
The type of the result is that of the promoted left operand. If the
value of the right operand is negative or is greater than or equal to
the width of the promoted left operand, the behavior is undefined.
(seems irrelevant here)
Is it intended to be a free-for-all, do you know?
> > Perhaps also let me know what else conversion does and does not apply
> > to?
>
> 6.5.5 "The usual arithmetic conversions are performed on the operands."
Those say
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.
which would convert the (left, signed) int type to the (right,
unsigned) int type. That has not been done.
I'm beginning to deduce there is a right old mess here. Glad we caught
it! Who knows what confusion might occur if this language ever sees the
light of day!
> 6.5.6 "The usual arithmetic conversions are performed on the operands."
Ditto. If TUAC are applied they make both arguments unsigned int in
this case by the rule "If one operand has an unsigned type T ..." that
I quoted above and that does not happen, so either there an no
conversions that apply or there is some kind of exception written down
somewhere.
I think we should just stop parsing text for sense in this instance and
say they got the language wrong in the spec, but we know what they mean.
> 6.5.7 [no mention of arithmetic conversions]
> 6.5.8 "If both of the operands have arithmetic type, the usual
> arithmetic conversions are performed."
Ditto.
> 6.5.9 "If both of the operands have arithmetic type, the usual
> arithmetic conversions are performed."
> etc.
Ditto.
> This was already said in the thread:
What "this"? Nothing has been said so far that amounts to a
constructive argument telling us whether or whether not "the usual
arithmetic conversions" must or may or must not or may not be performed
for a shift operator.
The best I have seen is that the words WHEN and MANY 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:
allow complete freedom of what happens. And I offered that explanation.
> https://gcc.gnu.org/ml/gcc-help/2018-02/msg00020.html
That is indeed THIS thread. Can you be specific about what the THIS
is that you say was said? It appears from your words to apply to "If
both of the operands have arithmetic type, the usual arithmetic
conversions are performed" which does not happen, unless you think the
"usual" is different from
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.
Do you?
It's OK if the text is not decisive, so long as it is determined
logically that it is so. You likely can point to more of the relevant
paragraphs.
Regards
PTB
More information about the Gcc-help
mailing list