Integer overflow

  • Thread starter Enrico 'Trippo' Porreca
  • Start date
E

Enrico 'Trippo' Porreca

I believe there can be an integer overflow, without a silent
wrap-around, in the following example:

int a = INT_MAX;
a++;

Am I right? Could this lead to an abnormal program termination in some
implementations?

If so, could this happen without an arithmetical operation, i.e. because
of an assignment between different-ranged integers? I mean:

int a = 12345;
char b = a;

Or is it just an arithmetical operation issue?
 
E

Enrico 'Trippo' Porreca

Mike said:
Yes, there can. When it happens, the language deems
it 'undefined behavior', which means anything is
allowed to happen.
Perfect.


If 12345 is outside the range of type 'char', then
data will be lost.

Suppose 12345 is indeed outside the range of 'char' on my platform. Do I
get undefined behaviour then? I guess b can contain almost anything
(from the point of view of the C standard).
 
E

Eric Sosman

Enrico said:
Suppose 12345 is indeed outside the range of 'char' on my platform. Do I
get undefined behaviour then? I guess b can contain almost anything
(from the point of view of the C standard).

From a "legalistic" standpoint, the Standard permits one
of two outcomes: Either `b' receives an implementation-defined
value, or an implementation-defined signal is raised.
From
a practical standpoint, nearly every implementation takes the
former course, silently delivering some kind of value to `b'.
(It's been thirty years since I last used a machine where the
option of raising a signal might have made sense -- and that
machine didn't have a C implementation.)

Note that the situation is a bit different for unsigned
integral types. `unsigned char c = a;' would not raise any
signal, and would always deliver a value to `c'. The exact
value would be implementation-defined because different
implementations can have differing numbers of bits in their
`char' objects, but once the implementation-specific value
of `UCHAR_MAX' is known, the value stored in `c' can be
predicted with certainty.
 
E

Enrico 'Trippo' Porreca

Eric said:
From a "legalistic" standpoint, the Standard permits one
of two outcomes: Either `b' receives an implementation-defined
value, or an implementation-defined signal is raised.
From
a practical standpoint, nearly every implementation takes the
former course, silently delivering some kind of value to `b'.
(It's been thirty years since I last used a machine where the
option of raising a signal might have made sense -- and that
machine didn't have a C implementation.)

Now it's perfectly clear. Thank you very much.
 
C

CBFalconer

Enrico said:
I believe there can be an integer overflow, without a silent
wrap-around, in the following example:

int a = INT_MAX;
a++;

Am I right? Could this lead to an abnormal program termination
in some implementations?
Yes.


If so, could this happen without an arithmetical operation,
i.e. because of an assignment between different-ranged
integers? I mean:

int a = 12345;
char b = a;

Again, yes. While many implementations silently convert such
overflows into nonsensical values, you cannot assume such. The
actual behaviour is undefined.
 
P

Peter Nilsson

CBFalconer said:
Enrico 'Trippo' Porreca wrote: ....

Again, yes. While many implementations silently convert such
overflows into nonsensical values, you cannot assume such. The
actual behaviour is undefined.

No. If char is unsigned, the behaviour is perfectly well defined.

If char is signed then the behaviour is implementation defined on C90
implementations.
 
C

CBFalconer

Peter said:
No. If char is unsigned, the behaviour is perfectly well defined.

If char is signed then the behaviour is implementation defined on
C90 implementations.

Touche. chars are different.
 
K

Kevin Easton

CBFalconer said:
Touche. chars are different.

It's nothing to do with chars. Integer overflow causes undefined
behaviour, but a conversion of a value that can't fit into the target
type is implementation-defined behaviour in C90. This has been gone
over on this newsgroup many times.

- Kevin.
 
C

CBFalconer

Kevin said:
It's nothing to do with chars. Integer overflow causes undefined
behaviour, but a conversion of a value that can't fit into the target
type is implementation-defined behaviour in C90. This has been gone
over on this newsgroup many times.

Did I say anything else? I simply accepted the correction that an
overflow into a char, be it plain, signed, unsigned, is different
from an integer overflow.
 
P

pete

You used the word "overflow", when the code in question
merely has the assignement of an out of range value
(assuming that 12345 is out of range for char in this case).
The assignement of an out of range value,
is different from overflow and
the behavior is implementation defined, not undefined.

.... and also assuming that char is signed.
If unsigned, then the behavior is defined.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top