Arithmetic and C

[Massimiliano Alberti]

Are there rules on how should the C behave with the arithmetic operations?
Are the overflows always ignored? And are they simply truncated? (if I have
a 16-bits unsigned short ints
unsigned short int a = 65535, b = 10; is a + b defined? And a * b? and b -
a?)

bye

 

[pete]

Are there rules on how should
the C behave with the arithmetic operations?
Yes.

Are the overflows always ignored? And are they simply truncated?'

unsigned arithmetic is like that.

(if I have a 16-bits unsigned short ints
unsigned short int a = 65535, b = 10; is a + b defined?
And a * b? and b - a?)

The complicated part about unsigned short, is that it is
subject to the "usual arithmetic conversions" in arithmetic
operations, and you don't know what type it promotes to.
If int can represent all of the values of unsigned short,
then unsigned short gets promoted to int,
(overflow is undefined for signed types like int)
otherwise it would get promoted to unsigned.

 

[Massimiliano Alberti]

The complicated part about unsigned short, is that it is

subject to the "usual arithmetic conversions" in arithmetic
operations, and you don't know what type it promotes to.
If int can represent all of the values of unsigned short,
then unsigned short gets promoted to int,
(overflow is undefined for signed types like int)
otherwise it would get promoted to unsigned.

But there can't be an overflow if you promote two unsigned shorts to a
(bigger) int... and if the int isn't bigger then the shorts won't be
promoted (I think) (it would be pointless).

--- bye

 

[pete]

But there can't be an overflow if you promote two unsigned shorts to a
(bigger) int... and if the int isn't bigger then the shorts won't be
promoted (I think) (it would be pointless).

If two unsigned short values are converted to type int,
and one value is INT_MAX and the other is 10,
then the sum of those two int values, is undefined.

 

[Massimiliano Alberti]

If two unsigned short values are converted to type int,

and one value is INT_MAX and the other is 10,
then the sum of those two int values, is undefined.

If the two unsigned short values are short values, how can they be INT_MAX?
They are SHORT! They can be at max USHORT_MAX!

--- bye

 

[Martin Dickopp]

Are there rules on how should the C behave with the arithmetic operations?
Are the overflows always ignored? And are they simply truncated? (if I have
a 16-bits unsigned short ints
unsigned short int a = 65535, b = 10; is a + b defined? And a * b? and b -
a?)

Unsigned integers have "wrap-around" semantics, i.e. the result is
reduced modulo the maximum value plus one. If USHRT_MAX is 65535 on
your system, the following program fragment

unsigned short int a = 65535, b = 10;
unsigned short c = a + b;
unsigned short d = a * b;
unsigned short e = b - a;

would cause c, d, e to be 9, 65526, 11, respectively. Note that due to
integer promotions, the result of the /expression/ a + b could well be
65545, if that number can be represented by type int.

Overflowing signed integers causes undefined behavior.

Martin

 

[pete]

If the two unsigned short values are short values,
how can they be INT_MAX?
They are SHORT! They can be at max USHORT_MAX!

CHAR_BIT equals 16
sizeof(short) equals 1
USHRT_MAX equals 65535
sizeof(int) equals 2
INT_MAX equals 65535
INT_MIN equals -65535

 

[Dan Pop]

unsigned arithmetic is like that.


The complicated part about unsigned short, is that it is
subject to the "usual arithmetic conversions" in arithmetic
operations, and you don't know what type it promotes to.
If int can represent all of the values of unsigned short,
then unsigned short gets promoted to int,
(overflow is undefined for signed types like int)

However, overflow is very unlikely to happen from a + b, if a and b
get promoted to int. INT_MAX == 65535 and USHRT_MAX == 65535 is
theoretically possible, but very wasteful in practice.

otherwise it would get promoted to unsigned.

And this is a good reason to avoid unsigned shorts, unless you have a
compelling reason for using them.

Dan

 

[Dan Pop]

Are there rules on how should the C behave with the arithmetic operations?

Signed arithmetic overflow causes undefined behaviour. Unsigned
arithmetic overflow causes the result to be reduced modulo the largest
representable value plus one. However, due to the integral promotions,
arithmetic between unsigned operands shorter than unsigned int may be
performed using signed int arithmetic.

Are the overflows always ignored? And are they simply truncated? (if I have
a 16-bits unsigned short ints
unsigned short int a = 65535, b = 10; is a + b defined? And a * b? and b -
a?)

All of them are (normally) defined, but not *well* defined, because the
result depends on the type of a and b *after* the integral promotions.
If unsigned short is a 16-bit type, there are two *likely* scenarios:

1. int is a 32-bit type, and then the results have type int and the values
65545, 655350 and -65525, respectively.

2. int is a 16-bit type, in which case the operands are promoted to
unsigned int, which is a 16-bit type, too. In this case, the results
have type unsigned int and the values 9, 65526 and 11, respectively.

One can also imagine "exotic" scenarios where these operations generate
signed integer overflow or yield unsigned results other than those
mentioned above, but these are highly unlikely to occur in practice
(that's why I called them "exotic").

So, if you want consistent results, avoid using unsigned short operands.

Dan

 

[Jack Klein]

CHAR_BIT equals 16
sizeof(short) equals 1
USHRT_MAX equals 65535
sizeof(int) equals 2
INT_MAX equals 65535
INT_MIN equals -65535

....all of which is a nice example of comp.lang.c pedantry, but I
guarantee you no such implementation exists. Or likely ever will.

 

[Old Wolf]

unsigned arithmetic is like that.

However, overflow is very unlikely to happen from a + b, if a and b
get promoted to int. INT_MAX == 65535 and USHRT_MAX == 65535 is
theoretically possible, but very wasteful in practice.

Borland/Turbo C for DOS, among others, has INT_MAX == 32767
and USHRT_MAX == 65535. I think this means that:
unsigned short s = 32767 + 10;
is UB (the constants are signed ints), but
unsigned short t = 32768 + 10;
is not (32768 is signed long, and 10 gets promoted to match).