«

I understand that when C does arithmetic on mixed signed/unsigned operands,
it will perform an unsigned operation (converting the signed value as best
it can to unsigned). That is, after mixed width operands have been taken
care of.

Is this actually correct, and if so what is the rationale behind that?

(I'm in the middle of a compiler for a similar language, and have to choose
between doing the same as C, using signed arithmetic instead (as this could
be more useful for typical values that would be encountered), or possibly
reporting an error).)

--
Bartc

On 04/05/2012 04:54 PM, BartC wrote:
>
> I understand that when C does arithmetic on mixed signed/unsigned operands,
> it will perform an unsigned operation (converting the signed value as best
> it can to unsigned). That is, after mixed width operands have been taken
> care of.
>
> Is this actually correct, and if so what is the rationale behind that?

What it does is a little more complicated than that, and varies
depending upon the operation being performed. For full details, see
section 6.5 of the standard. In many cases, integer promotions
(6.3.1.1p2) are performed - search for any word starting with "promot".
In most cases the "usual arithmetic conversions" (6.1.8p1) are
performed: if both operands have integer type, that includes the integer
promotions as a first step.

Mixed signed/unsigned operations are not always performed as unsigned
operations:

The integer promotions will convert an unsigned operand to 'int', rather
than 'unsigned int', if it is of lower integer conversion rank than
'int' and all values of that type can be represented in 'int'.

If the promoted type of one operand is unsigned, and has an integer
conversion rank lower than the promoted type of the other operand, which
happens to be signed, and if all values of unsigned type can be
represented in the signed type, then the usual arithmetic conversions
require that the operation be performed using signed arithmetic.

Note: the expression a + b can have a type different from the promoted
type of either a or b. For instance, adding a float complex and a long
double will result in a value of long double complex type. Adding an
unsigned int and a signed long long will result in an unsigned long long.

> (I'm in the middle of a compiler for a similar language, and have to choose
> between doing the same as C, using signed arithmetic instead (as this could
> be more useful for typical values that would be encountered), or possibly
> reporting an error).)

On 04/05/2012 05:28 PM, James Kuyper wrote:
....
> If the promoted type of one operand is unsigned, and has an integer
> conversion rank lower than the promoted type of the other operand, which
> happens to be signed, and if all values of unsigned type can be
> represented in the signed type, then the usual arithmetic conversions
> require that the operation be performed using signed arithmetic.
>
> ... Adding an
> unsigned int and a signed long long will result in an unsigned long long.

Correction: it "may result" in unsigned long long, but only if UINT_MAX
> LLONG_MAX.

That's permitted by the C standard, though rather unlikely. A much more
plausible case would be unsigned int and signed long, which will result
in unsigned long if UINT_MAX > LONG_MAX, or unsigned long and signed
long long, which will result in unsigned long long if ULONG_MAX > LLONG_MAX.