Req #49510 [Com]: boolean validation fails with FILTER_NULL_ON_FAILURE
| From: | pgarvin76 at gmail dot com | Date: | Fri, 26 Oct 2012 04:16:39 +0000 |
| Subject: | Req #49510 [Com]: boolean validation fails with FILTER_NULL_ON_FAILURE | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-174310@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=49510&edit=1
ID: 49510
Comment by: pgarvin76 at gmail dot com
Reported by: m dot kurzyna at crystalpoint dot pl
Summary: boolean validation fails with FILTER_NULL_ON_FAILURE
Status: Assigned
Type: Feature/Change Request
Package: Filter related
Operating System: Linux
PHP Version: 5.3.0
Assigned To: pajoye
Block user comment: N
Private report: N
New Comment:
Never mind my last comment. I was using the wrong executable when running the tests. The fix works.
However, this patch was not merged into the 5.3 branch. Can we get it merged for 5.3.19?
Previous Comments:
------------------------------------------------------------------------
[2012-10-26 03:32:23] pgarvin76 at gmail dot com
There was a fix committed in branch 5.4.8 (a26390ef0c22be3637795d9b5ab1c445e1d3f847). But the
problem still persists for me. The test file (bug49510.phpt) fails on my fresh build.
------------------------------------------------------------------------
[2012-09-12 20:22:38] dernelson at corelogic dot com
The question the developer is asking filter_var() is: "is boolean FALSE a valid boolean",
and the answer filter_var() is giving back is "nope." Regardless of the technical details
underlying the implementation, there is an obvious problem here.
Short of changing PHP so that (string)FALSE === '0' (hah), I would suggest an explicit
test case for boolean FALSE values, so that the function can return boolean FALSE in those cases,
instead of NULL.
------------------------------------------------------------------------
[2012-07-15 04:57:34] stas@php.net
Filters operate on strings. So any value that is passed to the filter_var() will
be coerced into string. This means (boolean)false and '' is exactly the same for
the filter. And that means the callbacks will be receiving strings too.
Now, the docs specifically say '' is a valid value for "boolean" filter and is
converted to false, so '' should not return NULL with FILTER_NULL_ON_FAILURE I
guess since it's documented not to be failure value.
------------------------------------------------------------------------
[2012-06-24 00:34:38] 2072 at teaser dot fr
Knowing this issue I wanted to make a boolean validation filter of my own using
FILTER_CALLBACK but it suffers from the same problem, these filters are not
"boolean safe".
It appears that what is to be validated is first converted to a string.
So when given (bool)true my callback actually receives (string)'1' and
(string)'' when given (bool)false.
There is definitely something wrong.
(I'm using PHP 5.3.8)
------------------------------------------------------------------------
[2010-09-01 13:55:06] schkovich at gmail dot com
filter_var(false,FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE)
// got NULL, expected false
That does not make sense at all! Further on, I have to agree with m.kurzyna that since false ===
(bool)"" filter_var("",FILTER_VALIDATE_BOOLEAN,FILTER_NULL_ON_FAILURE) should
return FALSE and not NULL.
Basically, as implemented, getting FALSE from filter_var(false,FILTER_VALIDATE_BOOLEAN) means that
validation failed. It appears to be a design problem since filter_var() as
specified will return FALSE if the filter fails making it impossible to distinguish if filter failed
or valid FALSE value is returned. Therefore, instead returning FALSE if
filter fails perhaps warning could be issued or even better exception thrown.
On addition when voting I've wrongly selected that I am not using the same version and the same
operating system. Correct ones are:
PHP Version => 5.3.2-1ubuntu4.2
System => Linux schkovich 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:21:58 UTC 2010 x86_64
------------------------------------------------------------------------
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=49510
--
Edit this bug report at https://bugs.php.net/bug.php?id=49510&edit=1