infinite for-loop and related question

infinite for-loop and related question

[Jason Mancini]

Hello,
So as I recall, the following can be an infinite loop now with optimizations, right?

  for (int i(1); i!=0; ++i) { ... }

What about:

  unsigned int x = 0xFFFFFFFFU;
  x = x+1;
  if (x) { ... can we get here because "positive x + 1 must still positive"? ... }

If not, given the first, why not?
Thanks,
Jason Mancini 		 	   		  

Re: infinite for-loop and related question

[Jonathan Wakely]

On 16 February 2011 20:09, Jason Mancini wrote:
>
> Hello,
> So as I recall, the following can be an infinite loop now with optimizations, right?
>
>   for (int i(1); i!=0; ++i) { ... }

Right.

> What about:
>
>   unsigned int x = 0xFFFFFFFFU;
>   x = x+1;
>   if (x) { ... can we get here because "positive x + 1 must still positive"? ... }
>
> If not, given the first, why not?

No.  The C and C++ standards define that unsigned integers do not
overflow, they wrap, with well-defined behaviour.

They do not define what happens if a signed integer overflows, so your
first loop results in undefined behaviour, and so you cannot
reasonably expect any particular behaviour. The compiler can do
whatever it likes with your code.

Put another way:
There is no way for a correct C or C++ program to increment a signed
integer greater than zero such that the result is zero. Because a
correct C or C++ program does not contain integer overflows.

RE: infinite for-loop and related question

[Jason Mancini]

> No. The C and C++ standards define that unsigned integers do not
> overflow, they wrap, with well-defined behaviour.

Aha, thank  you!

Though I still find the output of this odd:

  for (char i(1); i>0; ++i) 
    printf("%d %d\n", i, sizeof(i));

...
362195 1
362196 1
362197 1
...

For very large values of char!  ^_^

Jason

 		 	   		  

Re: infinite for-loop and related question

[Bob Plantz]

On 02/16/2011 12:41 PM, Jason Mancini wrote:
> Though I still find the output of this odd:
>
>    for (char i(1); i>0; ++i)
>      printf("%d %d\n", i, sizeof(i));
>
> ...
> 362195 1
> 362196 1
> 362197 1
> ...
>
> For very large values of char!  ^_^
>
> Jason
That's odd. With g++ 4.4.5 on an x86-64 machine in 64-bit mode I get:

---
125 1
126 1
127 1

which is what I would expect. That is, i is a (signed) char, and when it goes over 127 it becomes a negative number, so the loop terminates.

--Bob

Re: infinite for-loop and related question

[Jonathan Wakely]

On 16 February 2011 21:37, Bob Plantz wrote:
> On 02/16/2011 12:41 PM, Jason Mancini wrote:
>>
>> Though I still find the output of this odd:
>>
>>   for (char i(1); i>0; ++i)
>>     printf("%d %d\n", i, sizeof(i));
>>
>> ...
>> 362195 1
>> 362196 1
>> 362197 1
>> ...
>>
>> For very large values of char!  ^_^
>>
>> Jason
>
> That's odd. With g++ 4.4.5 on an x86-64 machine in 64-bit mode I get:
>
> ---
> 125 1
> 126 1
> 127 1
>
> which is what I would expect. That is, i is a (signed) char, and when it
> goes over 127 it becomes a negative number, so the loop terminates.

That would be the expected result if char was unsigned. But as I've
already explained up-thread, when a signed integer overflows you get
undefined behaviour.  If you enable optimisation you might get Jason's
result, or you might have demons fly out of your nose, or your hard
drive might get formatted*


* results may vary, empirically I've only seen it wrap to a negative
number or keep getting larger. But I avoid undefined behaviour because
I'm worried about the nasal demons. You should be too.

Re: infinite for-loop and related question

[Thomas Martitz]

Am 16.02.2011 22:49, schrieb Jonathan Wakely:
> On 16 February 2011 21:37, Bob Plantz wrote:
>> On 02/16/2011 12:41 PM, Jason Mancini wrote:
>>> Though I still find the output of this odd:
>>>
>>>    for (char i(1); i>0; ++i)
>>>      printf("%d %d\n", i, sizeof(i));
>>>
>>> ...
>>> 362195 1
>>> 362196 1
>>> 362197 1
>>> ...
>>>
>>> For very large values of char!  ^_^
>>>
>>> Jason
>> That's odd. With g++ 4.4.5 on an x86-64 machine in 64-bit mode I get:
>>
>> ---
>> 125 1
>> 126 1
>> 127 1
>>
>> which is what I would expect. That is, i is a (signed) char, and when it
>> goes over 127 it becomes a negative number, so the loop terminates.
> That would be the expected result if char was unsigned.

Not exactly, no? An unsiged char goes to 255.

Best regards.

Re: infinite for-loop and related question

[Jonathan Wakely]

On 16 February 2011 23:02, Thomas Martitz  wrote:
> Am 16.02.2011 22:49, schrieb Jonathan Wakely:
>>
>> On 16 February 2011 21:37, Bob Plantz wrote:
>>>
>>> On 02/16/2011 12:41 PM, Jason Mancini wrote:
>>>>
>>>> Though I still find the output of this odd:
>>>>
>>>>   for (char i(1); i>0; ++i)
>>>>     printf("%d %d\n", i, sizeof(i));
>>>>
>>>> ...
>>>> 362195 1
>>>> 362196 1
>>>> 362197 1
>>>> ...
>>>>
>>>> For very large values of char!  ^_^
>>>>
>>>> Jason
>>>
>>> That's odd. With g++ 4.4.5 on an x86-64 machine in 64-bit mode I get:
>>>
>>> ---
>>> 125 1
>>> 126 1
>>> 127 1
>>>
>>> which is what I would expect. That is, i is a (signed) char, and when it
>>> goes over 127 it becomes a negative number, so the loop terminates.
>>
>> That would be the expected result if char was unsigned.
>
> Not exactly, no? An unsiged char goes to 255.
>
> Best regards.
>

Well yeah, of course. But the value goes to zero and the loop terminates.

Re: infinite for-loop and related question

[Axel Freyn]

On Wed, Feb 16, 2011 at 01:37:03PM -0800, Bob Plantz wrote:
> On 02/16/2011 12:41 PM, Jason Mancini wrote:
>> Though I still find the output of this odd:
>>
>>    for (char i(1); i>0; ++i)
>>      printf("%d %d\n", i, sizeof(i));
>>
>> ...
>> 362195 1
>> 362196 1
>> 362197 1
>> ...
>>
>> For very large values of char!  ^_^
>>
>> Jason
> That's odd. With g++ 4.4.5 on an x86-64 machine in 64-bit mode I get:
>
> ---
> 125 1
> 126 1
> 127 1
But there is also a second "bug" in the program. You tell "printf", that
the variable "i" is a integer and not a char -- so printf will read
sizeof(int) Bytes at the adress of "i" in order to create the
output-number, which gives you the 362195.  You should write something
like
      printf("%d %d\n", (int)i, sizeof(i));
in order to get the "true" value of i in the output -- then I would
expect values in the "char"-range -127<i<128.


Axel

Re: infinite for-loop and related question

[Jonathan Wakely]

On 17 February 2011 09:44, Axel Freyn <axel-freyn@gmx.de> wrote:
> On Wed, Feb 16, 2011 at 01:37:03PM -0800, Bob Plantz wrote:
>> On 02/16/2011 12:41 PM, Jason Mancini wrote:
>>> Though I still find the output of this odd:
>>>
>>>    for (char i(1); i>0; ++i)
>>>      printf("%d %d\n", i, sizeof(i));
>>>
>>> ...
>>> 362195 1
>>> 362196 1
>>> 362197 1
>>> ...
>>>
>>> For very large values of char!  ^_^
>>>
>>> Jason
>> That's odd. With g++ 4.4.5 on an x86-64 machine in 64-bit mode I get:
>>
>> ---
>> 125 1
>> 126 1
>> 127 1
> But there is also a second "bug" in the program. You tell "printf", that
> the variable "i" is a integer and not a char -- so printf will read
> sizeof(int) Bytes at the adress of "i" in order to create the
> output-number, which gives you the 362195.  You should write something
> like
>      printf("%d %d\n", (int)i, sizeof(i));
> in order to get the "true" value of i in the output -- then I would
> expect values in the "char"-range -127<i<128.

I'm guessing you didn't bother to actually compile that and test it?

See 5.2.2 [expr.call] paragraph 7 in the C++ standard.  Arguments to
varargs functions are subject to integral promotions.

Re: infinite for-loop and related question

[Axel Freyn]

On Thu, Feb 17, 2011 at 11:36:53AM +0000, Jonathan Wakely wrote:
> On 17 February 2011 09:44, Axel Freyn <axel-freyn@gmx.de> wrote:
> > On Wed, Feb 16, 2011 at 01:37:03PM -0800, Bob Plantz wrote:
> >> On 02/16/2011 12:41 PM, Jason Mancini wrote:
> >>> Though I still find the output of this odd:
> >>>
> >>>    for (char i(1); i>0; ++i)
> >>>      printf("%d %d\n", i, sizeof(i));
> >>>
> >>> ...
> >>> 362195 1
> >>> 362196 1
> >>> 362197 1
> >>> ...
> >>>
> >>> For very large values of char!  ^_^
> >>>
> >>> Jason
> >> That's odd. With g++ 4.4.5 on an x86-64 machine in 64-bit mode I get:
> >>
> >> ---
> >> 125 1
> >> 126 1
> >> 127 1
> > But there is also a second "bug" in the program. You tell "printf", that
> > the variable "i" is a integer and not a char -- so printf will read
> > sizeof(int) Bytes at the adress of "i" in order to create the
> > output-number, which gives you the 362195.  You should write something
> > like
> >      printf("%d %d\n", (int)i, sizeof(i));
> > in order to get the "true" value of i in the output -- then I would
> > expect values in the "char"-range -127<i<128.
> 
> I'm guessing you didn't bother to actually compile that and test it?
Well, I did. But using gcc instead of g++. I get values <128 as soon as
I add the integer conversion (in C code).  
> See 5.2.2 [expr.call] paragraph 7 in the C++ standard.  Arguments to
> varargs functions are subject to integral promotions.
In C++ it does not make any difference.

Axel

Re: infinite for-loop and related question

[Jonathan Wakely]

On 17 February 2011 13:09, Axel Freyn wrote:
>>
>> I'm guessing you didn't bother to actually compile that and test it?
> Well, I did. But using gcc instead of g++. I get values <128 as soon as
> I add the integer conversion (in C code).

Jason's original code used char i(1) which is not valid C  ;-)

In any case, I get the same behaviour in C as C++, the cast to int
makes no difference.

Did you use optimization?

>> See 5.2.2 [expr.call] paragraph 7 in the C++ standard.  Arguments to
>> varargs functions are subject to integral promotions.
> In C++ it does not make any difference.

C has the same rules for default argument promotions, see 6.5.2.2 paragraph 6

Re: infinite for-loop and related question

[Bill McEnaney]

Although I doubt anyone would write it, this would work, wouldn't it?

int n = +10;

while ( n > 0)
   n += -1;

Bill

> On 16 February 2011 20:09, Jason Mancini wrote:
> >
> > Hello,
> > So as I recall, the following can be an infinite loop now with optimizations, right?
> >
> >   for (int i(1); i!=0; ++i) { ... }
> 
> Right.
> 
> > What about:
> >
> >   unsigned int x = 0xFFFFFFFFU;
> >   x = x+1;
> >   if (x) { ... can we get here because "positive x + 1 must still positive"? ... }
> >
> > If not, given the first, why not?
> 
> No.  The C and C++ standards define that unsigned integers do not
> overflow, they wrap, with well-defined behaviour.
> 
> They do not define what happens if a signed integer overflows, so your
> first loop results in undefined behaviour, and so you cannot
> reasonably expect any particular behaviour. The compiler can do
> whatever it likes with your code.
> 
> Put another way:
> There is no way for a correct C or C++ program to increment a signed
> integer greater than zero such that the result is zero. Because a
> correct C or C++ program does not contain integer overflows.
> 
> 

________________________________________________________________
Please visit a saintly hero:
http://www.jakemoore.org