Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Eventual undefined behaviour

Reply
Thread Tools

Eventual undefined behaviour

 
 
Spiros Bousbouras
Guest
Posts: n/a
 
      09-14-2007
#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 ?

 
Reply With Quote
 
 
 
 
Ravi
Guest
Posts: n/a
 
      09-14-2007
> 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!

 
Reply With Quote
 
 
 
 
Richard Tobin
Guest
Posts: n/a
 
      09-14-2007
In article <(E-Mail Removed). com>,
Ravi <(E-Mail Removed)> wrote:

>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
 
Reply With Quote
 
=?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=
Guest
Posts: n/a
 
      09-14-2007
On Fri, 14 Sep 2007 07:34:05 -0700, Spiros Bousbouras wrote:
> #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.
 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      09-14-2007
"Harald van D?k" <(E-Mail Removed)> a écrit dans le message de news:
fcecig$2a9$(E-Mail Removed)1.ov.home.nl...
> On Fri, 14 Sep 2007 07:34:05 -0700, Spiros Bousbouras wrote:
>> #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.


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.

--
Chqrlie.


 
Reply With Quote
 
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0Fk?=
Guest
Posts: n/a
 
      09-14-2007
On Fri, 14 Sep 2007 19:31:09 +0200, Charlie Gordon wrote:
> "Harald van D?k" <(E-Mail Removed)> a écrit dans le message de news:
> fcecig$2a9$(E-Mail Removed)1.ov.home.nl...
>> On Fri, 14 Sep 2007 07:34:05 -0700, Spiros Bousbouras wrote:
>>> int i ;
>>>
>>> for (i=1 ; i != 0 ; i++) ;

>
> 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.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      09-14-2007
Ravi wrote:
>
>> 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.


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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      09-14-2007
"Harald van D?k" <(E-Mail Removed)> a écrit dans le message de news:
fcemg2$ruk$(E-Mail Removed)1.ov.home.nl...
> On Fri, 14 Sep 2007 19:31:09 +0200, Charlie Gordon wrote:
>> "Harald van D?k" <(E-Mail Removed)> a écrit dans le message de news:
>> fcecig$2a9$(E-Mail Removed)1.ov.home.nl...
>>> On Fri, 14 Sep 2007 07:34:05 -0700, Spiros Bousbouras wrote:
>>>> int i ;
>>>>
>>>> for (i=1 ; i != 0 ; i++) ;

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


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

--
Chqrlie.


 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      09-14-2007
Charlie Gordon wrote:
>

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

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      09-14-2007
CBFalconer wrote, On 14/09/07 20:19:
> Ravi wrote:
>>> 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.

>
> 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.
--
Flash Gordon
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
The eventual end of crappy lithium batteries? RichA Digital Photography 36 10-31-2009 05:32 AM
typeof x == 'undefined' or x == undefined? -Lost Javascript 13 01-31-2007 12:04 AM
undefined vs. undefined (was: new Array() vs []) VK Javascript 45 09-12-2006 05:26 PM
undefined behavior or not undefined behavior? That is the question Mantorok Redgormor C Programming 70 02-17-2004 02:46 PM
undefined behaviour Dan Cernat C++ 1 11-11-2003 04:49 PM



Advertisments