Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The 2147483647 overflows resulting in a negative value directing PHP to 
create an array of an enourmous number of elements. To achieve the 
desired result you need to pass the parameters are doubles

Ex. var_dump( range(2147483646.0, 2147483647.0) );

HI Ilia,
        Again as with 41118 I reviewed this one prior to Mahesh
raising the defect and having reviewed your comments above I still believe this defect reports a valid issue in the PHP code.

As the value for low and high could be variables your suggestion that 
the request should be re-coded as range(2147483646.0, 2147483647.0)  
implies all user scripts would need to include range checks on calculated high and low values in order that the correct range()
request could be issued to avoid the bad behaviour reported by this defect, i.e script loops until storage is exhausted. This seems unnecessary and unacceptable to me. 

After reading the description of range() in the php manual I would 
expect 

	range(2147483646, 2147483647)

to create an array of int's with 2 entries as follows: 

array(2) {
   [0]=>
  int(2147483646)
  [1]=>
  int(2147483647)
}

I certainly would not expect an array with 2G entries. If the users
input causes overflow then that should be detected and reported.  

However, both the low and high values specified in the range() request
above are within the range which can be expressed as a 32 bit signed 
integer;  2147483647 is the MAX_INTEGER value. 

Further if I code something like range(2147483400, 2147483600, 100) 
where both high and low are clearly within range of valid int's I get 
the same bad behaviour, i.e  the PHP code loops creating a huge 
array because the logic in array.c does not detect overflow.

Please find here:
  
       http://www.pastebin.ca/447902

a patch to array.c based on latest PHP 52 branch from CVS which fixes 
the code to produce the output I would expect as per the description
in the PHP manual. 

The following testcase runs clean with the fix; without the fix a 
number of use cases cause bad/unexpected behaviour.

<?php
// posotive steps
var_dump(range(2147483400, 2147483600, 100));
var_dump( range(2147483646, 2147483648, 1 ) ); // OK
var_dump( range(2147483646, 2147483657, 1 ) ); // Loops without fix 
var_dump( range(2147483630, 2147483646, 5 ) ); // Loops without fix 
 
// negative steps  
var_dump( range(-2147483645, -2147483648, 1 ) ); // OK 
var_dump( range(-2147483645, -2147483649, 1 ) ); // OK 
var_dump( range(-2147483630, -2147483646, 5 ) ); // Loops without fix 

// low > high
var_dump(range(2147483647, 2147483645, 1 )); // Loops without fix 
var_dump(range(2147483648, 2147483645, 1 )); //OK 
 
?>

I am therefore re-opening the defect so that my propsed fix can be considered for inclusion.

Regards,
	Andy 


Andy Wharmby
IBM United Kingdom Limited
E-mail: andy_wharmby@uk.ibm.com

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.