# Input Filters - Bugs? - PHP4 Port

- Thread: https://externals.io/message/10779
- Original archive: https://news-web.php.net/php.internals/10779
- Started by Stefan Esser on 2004-06-25T18:36:59+00:00
- Messages: 4
- 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

---

## #10779 — Stefan Esser — 2004-06-25T18:36:59+00:00

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

Hi,

am I correct in assuming that input_filters are allowed todo whatever 
they want with the value?

I am asking, because this is not properly documented and atleast the 
mbstring extension violates this.

First of all it feeds input_filter a value pointer that is NOT allocated 
with emalloc and secondly it free()s the wrong address in case the 
input_filter has erealloc()ated value (but most probably the erealloc() 
will already crash because the memory is allocated with malloc() instead 
of emalloc())

And the second question is: Is there any argument against backporting 
the input_filter functionality to PHP4? I do not know what the plans 
are, but I doubt PHP4 will die out with the release of PHP5 and so the 
question is if we partly backport new functionality for PHP4 from PHP5 
into PHP 4.4

Stefan

---

## #10781 — Rasmus Lerdorf — 2004-06-26T08:24:23+00:00

URL: https://externals.io/message/10779#10781 · In reply to: #10779

> am I correct in assuming that input_filters are allowed todo whatever 
> they want with the value?
>
> I am asking, because this is not properly documented and atleast the 
> mbstring extension violates this.
> 
> First of all it feeds input_filter a value pointer that is NOT allocated 
> with emalloc and secondly it free()s the wrong address in case the 
> input_filter has erealloc()ated value (but most probably the erealloc() 
> will already crash because the memory is allocated with malloc() instead 
> of emalloc())

Yeah, this should probably be more strictly defined.  I think I am 
probably the only one using this and my filters never grow the string so I 
don't have these problems.

> And the second question is: Is there any argument against backporting 
> the input_filter functionality to PHP4? I do not know what the plans 
> are, but I doubt PHP4 will die out with the release of PHP5 and so the 
> question is if we partly backport new functionality for PHP4 from PHP5 
> into PHP 4.4

No real porting necessary.  This area of the code is identical in PHP4 and 
PHP5, so it would just be a matter of adding the hook.  I am using this 
extensively with PHP4.

-Rasmus

---

## #10782 — Stefan Esser — 2004-06-26T08:35:00+00:00

URL: https://externals.io/message/10779#10782 · In reply to: #10781

Hi,

> No real porting necessary.  This area of the code is identical in PHP4 and 
> PHP5, so it would just be a matter of adding the hook.  I am using this 
> extensively with PHP4.

I know. I "backported" it for my next version of Hardened-PHP which will 
make use of the input_filter system and will implement some kind of 
access (and content) control list for variables.

Stefan

---

## #10787 — Moriyoshi Koizumi — 2004-06-26T16:30:57+00:00

URL: https://externals.io/message/10779#10787 · In reply to: #10779

> I am asking, because this is not properly documented and atleast the 
> mbstring extension violates this.

mbstring extention doesn't actually use "input filter" stuff, but it
had initially been merged to SAPI as a ugly "hack" long before the input
filter was first introduced by Rasmus. So whatsoever it is, it has
nothing to do with that :) while I'm thinking of switching to more a 
generic facility,
with which values and keys can equally be altered in filter callbacks.

Moriyoshi