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

go to bug id or search bugs for

Bug #47745 FILTER_VALIDATE_INT doesn't allow minimum integer
Submitted: 2009-03-21 23:34 UTC Modified: 2009-03-31 10:06 UTC
From: for-bugs at hnw dot jp Assigned: dmitry (profile)
Status: Closed Package: Filter related
PHP Version: 5.2.9 OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: for-bugs at hnw dot jp
New email:
PHP Version: OS:

 

 [2009-03-21 23:34 UTC] for-bugs at hnw dot jp 
Description:
------------
Although -2147483648 is the minimum integer in 32bit environment, 
FILTER_VALIDATE_INT says -2147483648 is invalid as integer.

Reproduce code:
---------------
<?php

var_dump(intval("-2147483648"));
var_dump(filter_var("-2147483648", FILTER_VALIDATE_INT));

Expected result:
----------------
int(-2147483648)
int(-2147483648)

Actual result:
--------------
int(-2147483648)
bool(false)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-03-26 22:44 UTC] scottmac@php.net 
For some reason php_filter_parse_int multiplies the integer by ten then attempts to eat a 0? This is causing overflow and resulting in an error.

I have no idea why its doing this though. ilia?
 [2009-03-29 16:43 UTC] iliaa@php.net 
We don't eat a 0. When parsing #s we follow this logic:

Let's say X is our temp var containing the 1st digit and the number to 
be parsed is 435.

X = X * 10;
X += 3; (X = 43)

X = X * 10;
X += 5; (X = 435)

There is no 0 eating etc...
 [2009-03-29 16:47 UTC] pajoye@php.net 
The only problem is the value we use for the max unsigned range. It should be changed to allow - 2^31, but I did not check the code more in details, but Ilia is on it so :)
 [2009-03-29 21:38 UTC] scottmac@php.net 
Must have been sleep deprived when I looked at this last.
 [2009-03-30 19:47 UTC] iliaa@php.net 
The multiplication is done by the standard ZEND macro, so if there is a 
limit issue it needs to be handled inside the Zend Engine.

That said on my 64bit machine, I cannot reproduce the issue via -
PHP_INT_MAX
 [2009-03-31 09:27 UTC] for-bugs at hnw dot jp 
Result on 64bit environment:


$ php -r 'var_dump(intval((string)~PHP_INT_MAX));'
int(-9223372036854775808)
$ php -r 'var_dump(filter_var((string)~PHP_INT_MAX, FILTER_VALIDATE_INT));'
bool(false)


There is same problem on 64bit environment, I think.
 [2009-03-31 10:06 UTC] dmitry@php.net 
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.
 [2009-11-30 19:52 UTC] svn@php.net 
Automatic comment from SVN on behalf of jani
Revision: http://svn.php.net/viewvc/?view=revision&revision=291519
Log: MFH: removed last test for MAX_INT, did not work on x64 and this case is covered by bug47745.phpt
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Dec 03 17:01:29 2024 UTC