Edit report at https://bugs.php.net/bug.php?id=49510&edit=1
ID: 49510
Comment by: 2072 at teaser dot fr
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:
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)
Previous Comments:
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
[2009-09-10 11:24:37] m dot kurzyna at crystalpoint dot pl
As much as i'd like to have empty string be invalid false cast i have to
disagree with you for consistency reasons.
If (boolean)'' == false then filter_var('','boolean') should also return false.
Both in general and in case of FILTER_NULL_ON_FAILURE (just like the
documentation states).
Also, because i can't stress it enough, this is a VALIDATOR not a SANITIZER so
using it as a strict caster is secondary to it's validation purpose and as such
it currently fails both on implied and explicit behavior.
The ideal solution would be to have FILTER_VALIDATE_BOOLEAN roughly equal to
current behavior with FILTER_NULL_ON_FAILURE and a *seperate*
FILTER_SANITIZE_BOOLEAN similar to current behavior w/o the null failure flag.
This however probably is impossible due to BC.
------------------------------------------------------------------------
[2009-09-10 11:09:43] sjo...@php.net
I agree that filter_var() should return null for the empty string. I think that
this usage of filter_var() is meant to convert string representations of
booleans to boolean values. That is, "true", "on", "1", "false", "off" and "0"
should be converted, other strings should return null.
------------------------------------------------------------------------
[2009-09-10 09:05:53] m dot kurzyna at crystalpoint dot pl
Personally i think it's just fine (empty string ain't false - if anything it's
null) but in PHP world it is (both on PHP and C levels):
(string)false = ''
(boolean)'' == false
Z_STRLEN_P(value) = 0
Oh, and there is this little documentation thingy you like to cite from time to
time:
If FILTER_NULL_ON_FAILURE is set, FALSE is returned only for "0", "false",
"off", "no", and "", and NULL is returned for all non-boolean values.
where empty string is explicitly stated as being false.
------------------------------------------------------------------------
[2009-09-10 08:57:29] sjo...@php.net
Why do you think it is wrong that it returns null for an empty string?
------------------------------------------------------------------------
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
