# Smaller fix for the ext/filter boolean filter limitation (was Re: cvs: php-src /ext/filter long subject)

- Thread: https://externals.io/message/26240
- Original archive: https://news-web.php.net/php.internals/26240
- Started by Skalpa Keo on 2006-10-25T06:40:27+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #26240 — Skalpa Keo — 2006-10-25T06:40:27+00:00

URL: https://externals.io/message/26240#26240

Hi,

First my apologies for not being able to go a real reply to the real thread, 
but I just subscribed to the list a couple days ago (and the original thread 
subject was way too long anyway ;-)).

> > […]
> If it wasn't an issue I wouldn't have fixed it.

IMHO there's a more simple way to fix that without changing all the functions 
behavior. I think the distinction between `NULL` (non-existent data) and `FALSE` 
(invalid) should be kept and that having both cases return NULL, thus forcing 
users to use `filter_has_var()` to determine what this `NULL` means is a bit 
counter-intuitive.

A quite smaller modification of the boolean filter behavior could allow this 
(I'm sorry I can't send you a patch, but I'm a "PHP user" who hasn't touched 
a C source file for years... I'll try and do better next time if I can).

Make php_filter_boolean() return:
- (int)1 when the value is 1/on/true/yes
- (int)0 when the value is 0/off/false/no
- (bool)false when the value is something else

This is mostly backward compatible, as PHP considers that 0 == false and 1 == 
true, and would still allow people like Derick who'd need to make a 
difference between a "valid" boolean and an invalid value the possibility to 
do so by testing the returned value using ===.

Also, it would just require a small change in one single function, which I 
think would be more safe considering 5.2.0 is already an RC5.

Hoping I could be helpful,

skalpa.

---

## #26251 — Pierre — 2006-10-25T12:22:06+00:00

URL: https://externals.io/message/26240#26251 · In reply to: #26240

Hello,


>
> Hi,
>
> First my apologies for not being able to go a real reply to the real thread,
> but I just subscribed to the list a couple days ago (and the original thread
> subject was way too long anyway ;-)).
>
> > […]
>
> IMHO there's a more simple way to fix that without changing all the functions
> behavior. I think the distinction between `NULL` (non-existent data) and `FALSE` 
> (invalid) should be kept and that having both cases return NULL, thus forcing
> users to use `filter_has_var()` to determine what this `NULL` means is a bit
> counter-intuitive.

The problem is solved and a new flag has been commited, FILTER_NULL_ON_FAILURE.

--Pierre