php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #64450 mt_rand causes overflow within certain max value
Submitted: 2013-03-19 01:02 UTC Modified: 2013-03-26 19:44 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: stefano dot baccianella at gmail dot com Assigned: ab (profile)
Status: Wont fix Package: *General Issues
PHP Version: 5.4.13 OS: Windows 7 64bit
Private report: No CVE-ID: None
View Developer Edit
 [2013-03-19 01:02 UTC] stefano dot baccianella at gmail dot com 
Description:
------------
When using mt_rand function using pow(10,12) as MAX parameter the function seems 
to get an overflow giving the warning: PHP Warning:  mt_rand(): max(-727379968) 
is smaller than min(0)

But the function works perfectly when using greater MAX value like pow(10,13)


Below the diff of my php.ini and the php.ini-development provided by default:

short_open_tag = On
error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE
include_path = ".;C:\Program Files (x86)\PHP\pear"
extension=php_bz2.dll
extension=php_curl.dll
extension=php_gd2.dll
extension=php_gettext.dll
extension=php_mbstring.dll
extension=php_mysql.dll
extension=php_mysqli.dll
extension=php_openssl.dll
extension=php_pdo_pgsql.dll
extension=php_pgsql.dll
extension=php_apc.dll
extension=php_sockets.dll
;extension=php_sqlite.dll
extension=php_sqlite3.dll
date.timezone = Europe/Rome

[apc]

[APC]
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 512M
apc.num_files_hint = 1000
apc.user_entries_hint = 4096
apc.ttl = 0
apc.user_ttl = 0
apc.gc_ttl = 3600
apc.cache_by_default = 1
apc.filters = "apc\.php$"
apc.mmap_file_mask = "/tmp/apc.XXXXXX"
apc.slam_defense = 0
apc.file_update_protection = 2
apc.enable_cli = 0
apc.max_file_size = 10M
apc.use_request_time = 1
apc.stat = 1
apc.write_lock = 1
apc.report_autofilter = 0
apc.include_once_override = 0
apc.localcache = 0
apc.localcache.size = 256M
apc.coredump_unmap = 0
apc.stat_ctime = 0
apc.canonicalize = 1


Test script:
---------------
<?
  echo mt_rand(0,pow(10,12));
  echo mt_rand(0,pow(10,13));
?>

Expected result:
----------------
(a random number)(a random number)

Actual result:
--------------
PHP Warning:  mt_rand(): max(-727379968) is smaller than min(0)
(a random number)

Patches

bug64450.patch (last revision 2013-03-21 20:00 UTC by ab@php.net)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-03-21 14:03 UTC] ab@php.net 
The following patch has been added/updated:

Patch Name: bug64450.patch
Revision:   1363874609
URL:        https://bugs.php.net/patch-display.php?bug=64450&patch=bug64450.patch&revision=1363874609
 [2013-03-21 17:12 UTC] ab@php.net
-Assigned To: +Assigned To: ab
 [2013-03-21 20:00 UTC] ab@php.net 
The following patch has been added/updated:

Patch Name: bug64450.patch
Revision:   1363896006
URL:        https://bugs.php.net/patch-display.php?bug=64450&patch=bug64450.patch&revision=1363896006
 [2013-03-25 19:53 UTC] ab@php.net
-Status: Assigned +Status: Wont fix
 [2013-03-25 19:53 UTC] ab@php.net 
Reason: http://news.php.net/php.internals/66806

The function is documented to be able working in the int range. Except you've  
platform having true 64 bit long (which x64 windows is not), it's limited values 
within PHP_INT_MAX and (PHP_INT_MAX-1).
 [2013-03-25 20:03 UTC] stefano dot baccianella at gmail dot com 
I'm sorry but I don't agree with your explanation. 
If your explanation was valid the test mt_rand(0, 
pow(10,13)) would have failed but in fact is working.
 [2013-03-25 20:40 UTC] ab@php.net 
Please consider the following snippet

while(true) {
	$max = pow(10, 13); // 10000000000000
	$rand = mt_rand(0, $max);
	if ($rand > PHP_INT_MAX) {
		break;
	}
}

It *seems* to work, but you'll never reach the break condition. On some systems that 
might be PHP_INT_MAX*2, not sure. Thus, the whole range between pow(10, 13) and 
PHP_INT_MAX will never be returned.

Additionally please be aware - we deal with a pseudo randomness here, it works as 
expected in 32 bit range only with 32 bit long. The implementation seems to run 
unexpected overflows on some places like pow(10, 12) you've reported, but it just 
physically won't work with floats.

Thanks for reporting. A better solution is definitely needed for this functionality, 
not just a bug fix.
 [2013-03-25 20:47 UTC] stefano dot baccianella at gmail dot com 
Ok, now it's clear. 
Maybe as a minor fix I can suggest to check if MAX is greater than PHP_INT_MAX and 
return a value instead of an error (FALSE value?) or an error with an explanation, 
in both cases it's better than an overflow.

Thank you very much for your time
 [2013-03-25 23:22 UTC] ab@php.net 
I'm not sure something like that would be accepted as the valid domain is clearly 
documented and such a change is still a BC breach. What might work is a change 
request including an RFC for 5.6, otherwise a PECL ext.
 [2013-03-26 08:11 UTC] stefano dot baccianella at gmail dot com 
Yeah, true. I was misled by the fact that my system is 64bit but PHP for windows 
is compiled on 32bit.
I think that an RFC for 5.6 should be enough.
Thank you
 [2013-03-26 19:44 UTC] ab@php.net 
Well, Windows stands completely alongside. long on both x86 and x64 Windows is 32 
bit, so no matter which PHP build is used. The code we deal with here only works 
correct on system having sizeof(long) >= sizeof(double), that are for instance 64 
bit Linux or BSD.
 [2013-03-26 19:45 UTC] ab@php.net 
Linux or BSD 64 bit i mean.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Apr 28 09:01:27 2025 UTC