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 back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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