This bug seems to exists since version 5.4.8 as discussed here:

http://stackoverflow.com/questions/21469275/php-5-4-filter-var-filter-validate-boolean-bug-or-change-from-5-3

and being testable here:

http://3v4l.org/PB6sp

Yes, passing null as the first argument seems to be broken too. Please note that there is a difference between passing null and an object though: http://3v4l.org/oFCpE
Passing an object never worked correctly.

Keep in mind that the problem (if you pass booleans as well) is the string conversion happening before the filter is called. Making all Boolean checks impossible.

It appears that pajoye is correct; there is a convert_to_string call that messes all of this up. I'm not exactly sure what to do; it seems a rewrite is necessary to fix this behavior and that is beyond my current skill level. I could just bypass the convert_to_string call and special case this bug but that seems like a really bad idea.

I have a fix pending for when an object that does not have a __toString method is passed. Based on existing code and bug reports, it seems that casting to a string is by-design; this means that passing null to filter_var would get cast to '' (empty string) which results in filter_var returning false, not NULL (see http://www.php.net/manual/en/filter.filters.validate.php)

I have a PR open for this issue; hopefully it will get resolved soon.

According to the Documentation here: http://www.php.net/manual/en/filter.filters.validate.php

The filter FILTER_VALIDATE_BOOLEAN with the flag FILTER_NULL_ON_FAILURE shall "[return] NULL [...] for all non-boolean values".

In my opinion "null" is clearly a non-boolean value, so i can't really understand why you would classify it returning false as being "by design".

Here's the exact quote:

> 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.

It seems I misread; that does sound like it should return null for anything that fails `is_bool`.

I think FILTER_VALIDATE_BOOLEAN with FILTER_NULL_ON_FAILURE should return null for an array, an object that doesn't have __toString(), null, and a resource. For objects with __toString it depends on the result of the cast; the same goes for floats and integers.

Sound good?

Not 100% sure about it, but that sounds as close to the documentation we have as I can see.

> It appears that pajoye is correct; there is a convert_to_string call that messes > all of this up. 

One solution, not very nice and hackish, is to add a test along:

if not (filter==boolean && type in (integer, boolean)) convert to string 
then call the filter

> It appears that pajoye is correct; there is a convert_to_string
> call that messes all of this up.

I wonder why the first argument of filter_var() isn't string
instead of mixed.

I have applied a partial fix that works applies when you pass an object that doesn't have a `__toString` method. This will fix the specific code noted in test script, but won't fix some other cases (such as passing `null`)

Hi there,
Has this bugfix actually landed? If so, in which version, can't find it in the changelog.

I'm currently testing on PHP 5.6.11-1ubuntu3.1 and I can still reproduce the problem. Here is my test case:
<?php

class x {}

class y {
   public $m = 'n';

   function doStuff() {
      $this->m = 'l';
   }
}

$value = 'x';
var_dump(filter_var($value, FILTER_VALIDATE_BOOLEAN, FILTER_NULL_ON_FAILURE));
// expected: NULL – works as expected

$value = new stdClass();
var_dump(filter_var($value, FILTER_VALIDATE_BOOLEAN, FILTER_NULL_ON_FAILURE));
// expected: NULL – returns false

$value = new x();
var_dump(filter_var($value, FILTER_VALIDATE_BOOLEAN, FILTER_NULL_ON_FAILURE));
// expected: NULL – returns false

$value = new y();
var_dump(filter_var($value, FILTER_VALIDATE_BOOLEAN, FILTER_NULL_ON_FAILURE));
// expected: NULL – returns false


var_dump((string)$value);


This is the output I get:

NULL
bool(false)
bool(false)
bool(false)
PHP Catchable fatal error:  Object of class y could not be converted to string in /home/benedict/Repositories/wellid/testcase.php on line 30
PHP Stack trace:
PHP   1. {main}() /home/benedict/Repositories/wellid/testcase.php:0
benedict@minerva:~/Repositories/wellid$ vim testcase.php
benedict@minerva:~/Repositories/wellid$ php -f testcase.php 
NULL
bool(false)
bool(false)
bool(false)
PHP Catchable fatal error:  Object of class y could not be converted to string in /home/benedict/Repositories/wellid/testcase.php on line 30
PHP Stack trace:
PHP   1. {main}() /home/benedict/Repositories/wellid/testcase.php:0



As you can see, none of these have a __toString()-method.

Am I missing something?

Sorry, when pasting the output from the console, I pasted a little bit too much, hope it is still clear.

> Has this bugfix actually landed? If so, in which version, can't
> find it in the changelog.

The fix has only be applied to PHP 7.0.0+, and indeed, it's
missing in the changelog. I'm going to backport to PHP 5.6.

Hi guys,

Either this problem persist or i am doing something wrong here.I have PHP version 7.3.1 and the output of this:

filter_var(null, FILTER_VALIDATE_BOOLEAN, FILTER_NULL_ON_FAILURE)

is false, when it should be null according to the docs

Any ideas?

> is false, when it should be null according to the docs

No.  The filter_var() docs[1] state:

| Note that scalar values are converted to string internally
| before they are filtered.

So basically you're calling:

  filter_var('', FILTER_VALIDATE_BOOLEAN, FILTER_NULL_ON_FAILURE)

However, FILTER_VALIDATE_BOOLEAN is documented[2] to:

| If FILTER_NULL_ON_FAILURE is set, FALSE is returned only for
| "0", "false", "off", "no", and "" […]

So the behavior complies to the documentation.

[1] <http://php.net/manual/en/function.filter-var.php>
[2] <http://de2.php.net/manual/en/filter.filters.validate.php>