This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Integral conversions in C/C++
Christian BÃhme wrote:
> Andrew Haley wrote:
>
>> Section 5 Para. 9
>
> That's talking about _relational_ operators and starts with
>
> "The usual arithmetic conversions are performed on operands of
> arithmetic or enumeration type."
No, it isn't.
ISO/IEC 14882:1998(E)
5 Expressions
9
Many binary operators that expect operands of arithmetic or
enumeration type cause conversions and yield result types in a similar
way. The purpose is to yield a common type, which is also the type of
the result. This pattern is called the usual arithmetic conversions,
which are defined as follows:
- If either operand is of type long double, the other shall be
converted to long double.
- Otherwise, if either operand is double, the other shall be converted
to double.
- Otherwise, if either operand is float, the other shall be converted to float.
- Otherwise, the integral promotions (4.5) shall be performed on both
operands.54)
- Then, if either operand is unsigned long the other shall be
converted to unsigned long.
- Otherwise, if one operand is a long int and the other unsigned int,
then if a long int can represent all the values of an unsigned int,
the unsigned int shall be converted to a long int; otherwise both
operands shall be converted to unsigned long int.
- Otherwise, if either operand is long, the other shall be converted
to long.
- Otherwise, if either operand is unsigned, the other shall be
converted to unsigned. [Note: otherwise, the only remaining case is
that both operands are int ]
> going on about pointer conversions ectpp. My example did,
> however, neither. Any more pointers ?
>
>> and Section 4.5.
>
> That's "Integral promotions"
Well, yes. That's what applies here. The integral promotions
are relevant, because they are *directly* referred to in the
paragraph above.
> vs. 4.7 "Integral conversions" as in the subject of the OP.
Right, and you have now had the exact language quoted to you.
Your first example was
int64_t a;
uint32_t b = 8;
a = -(b * 2u);
So, the last section of Para 9 applies: b is promoted to unsigned
int, and the result, and unsigned int, is negated, yielding
another unsigned int.
In this case:
int64_t a;
uint32_t b = 8;
a = -((int64_t )(b * 2u));
the unsigned int result of (b * 2u) is converted to int64_t and
that is negated.
Andrew.