php.net |  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
Votes:8
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
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
Description:
------------
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:
---------------
--TEST--
Checks if the negative PHP_INT_MAX is treated as integer.
--CREDITS--
Eriksen Costa <eriksen.costa@infranology.com.br>
--SKIPIF--
<?php
if (PHP_INT_SIZE < 8) die('64bit platforms only');
?>
--FILE--
<?php
var_dump(-9223372036854775807 - 1);
var_dump((PHP_INT_MAX * -1) - 1);
var_dump(-9223372036854775808);
?>
--EXPECT--
int(-9223372036854775808);
int(-9223372036854775808);
int(-9223372036854775808);

Expected result:
----------------
int(-9223372036854775808);
int(-9223372036854775808);
int(-9223372036854775808);

Actual result:
--------------
int(-9223372036854775808)
int(-9223372036854775808)
float(-9.2233720368548E+18)


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-02-05 17:34 UTC] cataphract@php.net
-Status: Open +Status: Verified
 [2011-02-05 18:55 UTC] cataphract@php.net
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
@catphract:

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-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC