Velocity Reviews > Integer overflow

# Integer overflow

Enrico 'Trippo' Porreca
Guest
Posts: n/a

 08-21-2003
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?

Enrico 'Trippo' Porreca
Guest
Posts: n/a

 08-21-2003
Mike Wahler wrote:
> Enrico 'Trippo' Porreca <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>>I believe there can be an integer overflow,

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

Perfect.

>>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;

>
> 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).

Eric Sosman
Guest
Posts: n/a

 08-21-2003
Enrico 'Trippo' Porreca wrote:
>
> Mike Wahler wrote:
> > Enrico 'Trippo' Porreca <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> >
> >>I believe there can be an integer overflow,

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

>
> Perfect.
>
> >>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;

> >
> > 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).

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.

--
http://www.velocityreviews.com/forums/(E-Mail Removed)

Enrico 'Trippo' Porreca
Guest
Posts: n/a

 08-21-2003
Eric Sosman wrote:
> 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.

CBFalconer
Guest
Posts: n/a

 08-21-2003
Enrico 'Trippo' Porreca wrote:
>
> 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.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.

Peter Nilsson
Guest
Posts: n/a

 08-21-2003
CBFalconer <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> Enrico 'Trippo' Porreca wrote:

....
> > 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.

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

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

--
Peter

CBFalconer
Guest
Posts: n/a

 08-22-2003
Peter Nilsson wrote:
> CBFalconer <(E-Mail Removed)> wrote:
> > Enrico 'Trippo' Porreca wrote:

> ...
> > > 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.

>
> 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.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.

Kevin Easton
Guest
Posts: n/a

 08-24-2003
CBFalconer <(E-Mail Removed)> wrote:
> Peter Nilsson wrote:
>> CBFalconer <(E-Mail Removed)> wrote:
>> > Enrico 'Trippo' Porreca wrote:

>> ...
>> > > 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.

>>
>> 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.

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.

CBFalconer
Guest
Posts: n/a

 08-24-2003
Kevin Easton wrote:
>
> CBFalconer <(E-Mail Removed)> wrote:
> > Peter Nilsson wrote:
> >> CBFalconer <(E-Mail Removed)> wrote:
> >> > Enrico 'Trippo' Porreca wrote:
> >> ...
> >> > > 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.
> >>
> >> 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.

>
> 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.

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.

pete
Guest
Posts: n/a

 08-24-2003
pete wrote:
>
> CBFalconer wrote:
> >
> > Kevin Easton wrote:
> > >
> > > CBFalconer <(E-Mail Removed)> wrote:
> > > > Peter Nilsson wrote:
> > > >> CBFalconer <(E-Mail Removed)> wrote:
> > > >> > Enrico 'Trippo' Porreca wrote:
> > > >> ...
> > > >> > > int a = 12345;
> > > >> > > char b = a;

> 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.

--
pete