Usual Arithmetic Conversions-arithmetic expressions

[joshc]

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(+0x8000000 0), 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.

[bjrnove]

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

[joshc]

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
getting their information about this.

[bjrnove]

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
about what should happend.

Here is some words about the issue:
http://publications.gbdirect.co.uk/c...ral_types.html

--
bjrnove

[Old Wolf]

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(+0x8000000 0), 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.

[Keith Thompson]

"Old Wolf" <ol*****@inspir e.net.nz> 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(+0x8000000 0), 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_Keit h) ks***@mib.org <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.