Eventual undefined behaviour

[Spiros Bousbouras]

#include <stdio.h>

int main(void) {
int i ;

for (i=1 ; i != 0 ; i++) ;
printf("Finished !\n") ;
return 0 ;
}

Assume that a compiler is clever enough to realise that the
above will eventually overflow i. Can it refuse to produce an
executable on that basis ?

 

[Ravi]

Assume that a compiler is clever enough to realise that the

above will eventually overflow i. Can it refuse to produce an
executable on that basis ?

It won't. Eventually i will become -ve after reaching it +ve maximum
and then it will become 0. So it will terminate.
Hurray!

 

[Richard Tobin]

It won't. Eventually i will become -ve after reaching it +ve maximum
and then it will become 0. So it will terminate.

On most machines, but it's not guaranteed.

-- Richard

 

[=?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=]

#include <stdio.h>

int main(void) {
int i ;

for (i=1 ; i != 0 ; i++) ;
printf("Finished !\n") ;
return 0 ;
}

Assume that a compiler is clever enough to realise that the above will
eventually overflow i. Can it refuse to produce an executable on that
basis ?

Yes, but only because it can be proven that the loop will always execute.
If the function were named differently, and the compiler could no longer
prove it would be called unconditionally, then the compiler would have to
accept the code.

 

[Charlie Gordon]

Yes, but only because it can be proven that the loop will always execute.
If the function were named differently, and the compiler could no longer
prove it would be called unconditionally, then the compiler would have to
accept the code.

if i was defined as an unsigned variable, the behaviour is well defined and
I see no reason for the compiler to complain. If it is smart enough, it
will optimize to loop away.

With i as an int, it depends on the implementation whether the behaviour is
undefined or not. The compiler could detect the inevitable integer overflow
and complain about it, or even refuse to produce an executable, but on most
architectures the behaviour is defined and the loop can be optimized away.

 

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

With i as an int, it depends on the implementation whether the behaviour
is undefined or not. The compiler could detect the inevitable integer
overflow and complain about it, or even refuse to produce an executable,
but on most architectures the behaviour is defined and the loop can be
optimized away.

Implementations are allowed to define the behaviour on signed integer
overflow as an extension, but as far as I'm aware, most don't. If you try
it, usually, you'll see the wraparound you probably expect, but you
shouldn't rely on it unless it's documented, or your code may well end up
broken for newer versions of the compiler. This happened quite a bit with
GCC 4.2, and will probably occur again with different versions or
different compilers.

 

[CBFalconer]

It won't. Eventually i will become -ve after reaching it +ve
maximum and then it will become 0. So it will terminate.

The above *erroneous* statement needs rapid stomping. In C, any
integer overflow results in undefined behaviour. Some systems may
resolve that to resolving to a negative value, but even then which
value is variable (think 1's and 2's complement arithmetic). If
you want to handle overflow consistently, used unsigned integers,
which do modulo arithmetic.

 

[Charlie Gordon]

Implementations are allowed to define the behaviour on signed integer
overflow as an extension, but as far as I'm aware, most don't. If you try
it, usually, you'll see the wraparound you probably expect, but you
shouldn't rely on it unless it's documented, or your code may well end up
broken for newer versions of the compiler. This happened quite a bit with
GCC 4.2, and will probably occur again with different versions or
different compilers.

Come on, what gcc target does not do simple wrap around on signed integer
overflow ?

 

[CBFalconer]

.... snip ...

Come on, what gcc target does not do simple wrap around on signed
integer overflow ?

At least any that implement overflow traps. I can set up the 8088
to do just that.

 

[Flash Gordon]

CBFalconer wrote, On 14/09/07 20:19:

The above *erroneous* statement needs rapid stomping. In C, any
integer overflow results in undefined behaviour. Some systems may
resolve that to resolving to a negative value, but even then which
value is variable (think 1's and 2's complement arithmetic). If
you want to handle overflow consistently, used unsigned integers,
which do modulo arithmetic.

Note that some processors (the ones I know are DSPs have the ability to
limit at maximum +ve/-ve. So a loop of the form
for (i=1 ; i != 0 ; i++) ;
Would actually loop forever if the processor was put in that mode.

 

[Charlie Gordon]

At least any that implement overflow traps. I can set up the 8088
to do just that.

Yes, but do you have an OS or even a program that runs in this mode ?

 

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

Come on, what gcc target does not do simple wrap around on signed
integer overflow ?

All of them, regardless of the behaviour of the underlying hardware. The
standard allows

int f(int x) {
return x + 1 > x;
}

to be optimised to

int f(int x) {
return 1;
}

and gcc does exactly that.

 

[Jack Klein]

if i was defined as an unsigned variable, the behaviour is well defined and
I see no reason for the compiler to complain. If it is smart enough, it
will optimize to loop away.

With i as an int, it depends on the implementation whether the behaviour is
undefined or not. The compiler could detect the inevitable integer overflow

Signed integer overflow or underflow is always undefined.

and complain about it, or even refuse to produce an executable, but on most
architectures the behaviour is defined and the loop can be optimized away.

No, in C it is always undefined behavior. The result may be
predictable and repeatable on a particular platform, but that doesn't
make it defined.

Predictable and repeatable results are one possible consequence of
undefined behavior.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Spiros Bousbouras]

Note that some processors (the ones I know are DSPs have the ability to
limit at maximum +ve/-ve.

What does "ve" mean ? Neither dictionary.com nor
acronymfinder.com gave me a definition which makes
sense in this context.

outOfTopic {
What does it mean for a DSP to "limit" ? I've
never seen "limit" being used as an intransitive
verb.
}

 

[CBFalconer]

Yes, but do you have an OS or even a program that runs in this mode ?

Yes.

 

[Charlie Gordon]

Yes.

I'm impressed !
We should call that a DS8088

 

[Bart van Ingen Schenau]

At least any that implement overflow traps. I can set up the 8088
to do just that.

Or any target that has saturation arithmetic (the value is clipped in
the range of representable values).
Not all the world is a VAX!

Bart v Ingen Schenau

 

[Flash Gordon]

Spiros Bousbouras wrote, On 15/09/07 14:23:

What does "ve" mean ? Neither dictionary.com nor
acronymfinder.com gave me a definition which makes
sense in this context.

+ve is a fairly well known abbreviation for positive in England and I
suspect a number of other countries. I'll let you work out what -ve is.

outOfTopic {
What does it mean for a DSP to "limit" ? I've
never seen "limit" being used as an intransitive
verb.
}

With a 16 bit int
i = 0x7FFF;
i++; /* i is *still* 0x7FFF */

 

[Keith Thompson]

What does "ve" mean ? Neither dictionary.com nor
acronymfinder.com gave me a definition which makes
sense in this context.

"+ve" means "positive", "-ve" means "negative".

outOfTopic {
What does it mean for a DSP to "limit" ? I've
never seen "limit" being used as an intransitive
verb.
}

I think it refers to saturation, meaning that a computation that
overflows yields an extreme value of the type. For example, INT_MAX +
1 would yield INT_MAX; INT_MIN * 3 would yield INT_MIN.

 

[Bart van Ingen Schenau]

What does "ve" mean ? Neither dictionary.com nor
acronymfinder.com gave me a definition which makes
sense in this context.

+ve is shorthand for 'positive'. -ve is shorthand for 'negative'.
The sign in front of the ve is significant here.

outOfTopic {
What does it mean for a DSP to "limit" ? I've
never seen "limit" being used as an intransitive
verb.
}

It is also known a saturating arithmetic.
With saturating arithmetic, the following holds:
int foo = INT_MAX;
foo++;
assert(foo == INT_MAX);
(and similar for decrement of lowest value).

Bart v Ingen Schenau