Hello, On 12/8/06, Stefan Esser <[EMAIL PROTECTED]> wrote:
> This is where you are incorrect, take a look at > php_register_variable_safe() line #51. The reason we don't apply magic > quotes for PARSE_STRING (retval == 1) is because the return value of > the function in this instance is 1, which causes > php_register_variable_safe() to be executed on the returned value. > Indeed my fault. (Just another argument for b) the code paths is completely unobvious) >> a) support daisy chaining > > Can you not provide your own hooks and have them call the stock filter > functions? I (my extensions) have no problem with that. I just wonder why PHP got input filter hooks in one version and in a few versions later they are not useable anymore, because ext/filter grabs them.
For good reasons, if one can work around filter, filter itself makes no sense.
>> b) does not register the variables itself but actually work as filters >> were supposed to do. > I think it makes the API simpler, but it would not be major change to > make if there was a really good reason to do so. The reason is simple: The filter extension abuses the input filtering hooks. The variables are no longer registered at one single place but several codepaths lead to different results. The bug you fixed with your commit is the best example: If ext/filter would not try to register the variables itself, this bug would never have happened.
There is a bug with magic quotes (which aim to disappear in 6.x).
>> c) Support Cookies correctly... Very simple: In some earlier version php_register_variable_ex was changed to handle cookies different from other variables: Cookies with the same name will get dropped after the first is registered. In ext filter the raw variables still have this behaviour but the filtered variables behave different...
If you have found a bug, can you please open a bug here: http://bugs.php.net It will be easier for us to track it. Btw, the cvs list is not a discussion list, I moved this thread to internals. Thank you. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
