# Usual Arithmetic Conversions-arithmetic expressions

Discussion in 'C Programming' started by joshc, Mar 29, 2005.

1. ### joshcGuest

After reading the Standard section 6.3 multiple times and consulting
K&R I can't seem to figure out what would happen in the following case
assuming longs are 32 bits(have typedefs for this):

unsigned long int result;
signed long int x, y;

x = 0x7FFF8000;
y = -0x8000;

result = x - y;

I am trying to figure out what happens in this case. From my
understanding both operands will be converted to their common real type
which in this case will be 'signed long int'(no conversion). After the
subtraction is performed then the result will be converted to an
'unsigned long int'. Since this subtraction results in a positive
number that can't be represented in a signed long(+0x80000000), what
happens in this case? Can someone walk me through this step by step?
That would really help me understand this.

Also, anyone have a good suggestion for a book that goes over this type
of thing? My reading of the standard and K&R didn't help me. Maybe some
kind of annotated standard but obviously the Schildt book is worthless.

Thanks.

joshc, Mar 29, 2005

2. ### bjrnoveGuest

Correct me if I'm wrong, but I'm pretty shure the result here is
undefined by the standard and should not happen. I guess you will have
to test it on the compilers you want to use it on.

--
bjrnove

bjrnove, Mar 29, 2005

3. ### joshcGuest

bjrnove wrote:
> Correct me if I'm wrong, but I'm pretty shure the result here is
> undefined by the standard and should not happen. I guess you will

have
> to test it on the compilers you want to use it on.
>
> --
> bjrnove

Yeah I guess my thread subject should have been about overflow since my
question is about overflow as opposed to UAC it seems. I found some old
threads on overflow but I'm not sure where in the standard people are

joshc, Mar 29, 2005
4. ### bjrnoveGuest

A unsigned type will never overflow. So the code below will be handled
the same way on every system:

unsigned int ui = 0;

while(ui >= 0) /* Always true */
printf("%i\n", ui);

It will print all the numbers you can fit in an int and then start on 0
again. If you do the same thing again with a unsigned int you will get
various results, and I'm pretty shure the standard doesn't say anything

Here is some words about the issue:
http://publications.gbdirect.co.uk/c_book/chapter2/integral_types.html

--
bjrnove

bjrnove, Mar 29, 2005
5. ### Old WolfGuest

joshc wrote:
> After reading the Standard section 6.3 multiple times and
> consulting K&R I can't seem to figure out what would happen
> in the following case assuming longs are 32 bits:
>
> unsigned long int result;
> signed long int x, y;
>
> x = 0x7FFF8000;
> y = -0x8000;
>
> result = x - y;
>
> I am trying to figure out what happens in this case. From
> my understanding both operands will be converted to their
> common real type which in this case will be 'signed long
> int'(no conversion). After the subtraction is performed
> then the result will be converted to an 'unsigned long int'.
> Since this subtraction results in a positive number that
> can't be represented in a signed long(+0x80000000), what
> happens in this case?

Undefined behaviour (signed integer overflow). The UB
occurs before the conversion to unsigned long (so there
might never be a conversion to unsigned long and never
be an assignment to 'result').

> Can someone walk me through this step by step?

You just walked yourself through it quite well.

Old Wolf, Mar 30, 2005
6. ### Keith ThompsonGuest

"Old Wolf" <> writes:
> joshc wrote:
>> After reading the Standard section 6.3 multiple times and
>> consulting K&R I can't seem to figure out what would happen
>> in the following case assuming longs are 32 bits:
>>
>> unsigned long int result;
>> signed long int x, y;
>>
>> x = 0x7FFF8000;
>> y = -0x8000;
>>
>> result = x - y;
>>
>> I am trying to figure out what happens in this case. From
>> my understanding both operands will be converted to their
>> common real type which in this case will be 'signed long
>> int'(no conversion). After the subtraction is performed
>> then the result will be converted to an 'unsigned long int'.
>> Since this subtraction results in a positive number that
>> can't be represented in a signed long(+0x80000000), what
>> happens in this case?

>
> Undefined behaviour (signed integer overflow). The UB
> occurs before the conversion to unsigned long (so there
> might never be a conversion to unsigned long and never
> be an assignment to 'result').

It's also worth mentioning that, on many systems, the undefined
behavior will manifest itself as a wraparound. On such systems, the
result of the subtraction will be -0x80000000 (LONG_MIN), which when
converted to unsigned long will yield 0x80000000. (Once you get the
-0x80000000, the conversion is well defined; it's only the subtraction
that triggers undefined behavior.) This assumes a 2's-complement
representation.

Undefined behavior is usually to be avoided, but it can be useful to
know how it's likely to behave in real life (while keeping firmly in
mind that undefined really does mean undefined, and the standard makes
no guarantees).

--
Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Keith Thompson, Mar 31, 2005