Edit report at https://bugs.php.net/bug.php?id=66682&edit=1
ID: 66682
Updated by: rasmus@php.net
Reported by: alex dot howansky at gmail dot com
Summary: FILTER_VALIDATE_INT fails on strings starting with
zero.
Status: Not a bug
Type: Bug
Package: Filter related
Operating System: Linux 2.6 64
PHP Version: 5.5.9
Block user comment: N
Private report: N
New Comment:
Alex, you are mixing up two different things though. Intval() is a decimal cast operation. Same for
applying math operators. A forced cast has nothing to do with a string validator. The string
validator has a number of options, including whether or not you want to consider octal or hex
notations valid. If you simply want the PHP integer value of a string, just cast it. If you want to
check if something is a valid-looking integer for interacting with other systems, use the validator.
Something like '00' and '09' are both problematic since they are not decimal
integers in standard form and this could cause problems when passed to other systems. How PHP treats
'00' and '09' internally is completely irrelevant since PHP is only one possible
target for such data.
Previous Comments:
------------------------------------------------------------------------
[2014-02-16 22:16:32] yohgaki@php.net
Isn't it easier with validate them for each?
php_filter_int()
php_filter_octal()
php_filter_hex()
Perhaps?
BTW, if it could return string. It would be nice. Databases may have much higher precision.
------------------------------------------------------------------------
[2014-02-16 21:57:20] yohgaki@php.net
Hi Derick,
I'm not sure if this behavior is documented somewhere, but it seems strange. Tests do not cover
"01.23" nor "01" also, for example. I found this note http://jp2.php.net/manual/en/filter.filters.validate.php
but nothing else.
Note:
As of PHP 5.4.11, the numbers +0 and -0 validate as both integers as well as floats (using
FILTER_VALIDATE_FLOAT and FILTER_VALIDATE_INT). Before PHP 5.4.11 they only validated as floats
(using FILTER_VALIDATE_FLOAT).
When default is set to option, default's value is used if value is not validated.
If we are not going to fix this, this behavior should be documented if it's not already there.
So make this a documentation problem?
BTW, I haven't test much, but the patch in github invalidates "01",
"01.123", etc.
------------------------------------------------------------------------
[2014-02-16 21:38:26] alex dot howansky at gmail dot com
OK, understood. Unfortunately, this leaves an odd hole when working with strings that start with
zero and contain an eight or nine. For example, intval() only performs octal validation if you
explicitly override the base parameter's default value of 10. As a result,
intval('09') gives you exactly what you'd expect -- int(9). Likewise, '09'
+ 1 works just as expected, in base 10. However, regardless of flags, FILTER_VALIDATE_INT can never
return true for string '09'. Given that '09' is perfectly acceptable input for
other cases which require an int, this seems inconsistent. Perhaps a new option should be added to
this filter, named "base" or similar, which functions like the optional "base"
argument of intval().
------------------------------------------------------------------------
[2014-02-16 19:17:39] rasmus@php.net
By definition an integer with a leading zero is octal notation so 00 is octal 0. There is a flag to
explicitly allow octal integers which should also tell you that validate_int validates integers
written in decimal notation by default.
------------------------------------------------------------------------
[2014-02-16 18:52:55] alex dot howansky at gmail dot com
Also, consider this:
var_dump(filter_var('0', FILTER_VALIDATE_INT));
var_dump(filter_var('00', FILTER_VALIDATE_INT));
Returns:
int(0)
bool(false)
That's incredibly counter-intuitive.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=66682
--
Edit this bug report at https://bugs.php.net/bug.php?id=66682&edit=1