|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #53934 The negative PHP_INT_MAX is incorrectly converted to float
Submitted: 2011-02-05 14:53 UTC Modified: 2011-02-05 18:55 UTC
Avg. Score:4.1 ± 0.9
Reproduced:6 of 6 (100.0%)
Same Version:1 (16.7%)
Same OS:4 (66.7%)
From: eriksen dot costa at infranology dot com dot br Assigned:
Status: Verified Package: Scripting Engine problem
PHP Version: 5.3.5 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: eriksen dot costa at infranology dot com dot br
New email:
PHP Version: OS:


 [2011-02-05 14:53 UTC] eriksen dot costa at infranology dot com dot br
I found this and seems a bug. Everytime I use the negative PHP_INT_MAX literally (-9223372036854775808) as a function parameter, it is converted to float.

However, if I pass it like an expression -9223372036854775807 - 1, it is correctly identified as an integer.

Test script:
Checks if the negative PHP_INT_MAX is treated as integer.
Eriksen Costa <>
if (PHP_INT_SIZE < 8) die('64bit platforms only');
var_dump(-9223372036854775807 - 1);
var_dump((PHP_INT_MAX * -1) - 1);

Expected result:

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-02-05 17:34 UTC]
-Status: Open +Status: Verified
 [2011-02-05 18:55 UTC]
The problem is that "-9223372036854775808" is not parsed as an integer, instead the minus sign and the rest are parsed individually and 9223372036854775808 is bigger than LONG_MAX.

Probably this is not trivial to fix.
 [2012-08-09 14:05 UTC] ajf at ajf dot me

In that case is it not a tokeniser issue, and "-9223372036854775807" should be 
tokenised to '-9223372036854775807' not '-' '9223372036854775807'?
 [2014-06-05 14:37 UTC] ajf at ajf dot me
This issue still exists in master.
 [2014-06-05 15:12 UTC] ajf at ajf dot me
OK, I found out why this happens. Because the difference between subtraction and negation can't be known at lexing time ($x = 12-3 vs $x = -3), -9223372036854775808 is actually parsed as -(9223372036854775808). Since signed integers are asymettrical (max is 9223372036854775807 but min is -9223372036854775808), 9223372036854775808 overflows and becomes a float. Then the parser sees -(9.2233720368548E+18) and subtracts it, yielding -9.2233720368548E+18.

I'm not sure how this could be fixed short of parsing numbers at the last minute. Maybe that would actually reap performance benefits!
 [2015-12-19 23:27 UTC] ajf at ajf dot me
Since PHP 7 there is PHP_INT_MIN for this purpose, by the way.
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC