ID: 40947 User updated by: exaton at free dot fr Reported By: exaton at free dot fr -Status: Assigned +Status: Open -Bug Type: Filter related +Bug Type: Feature/Change Request Operating System: WinXP SP2, Debian PHP Version: 5.2.1 Assigned To: pajoye New Comment:
Thank you for taking the time to look at this, Pierre. My thanks to the others as well. As it happens, I believe I will follow your recommendation anyway and use filter_var() for the purpose studied here, reserving filter_var_array() for argument => definition fine-grained validation. But I was intrigued by the "semi"-typo in the code. So long all, keep up the excellent work ! David Holmes Previous Comments: ------------------------------------------------------------------------ [2007-03-29 13:52:35] [EMAIL PROTECTED] Just commit this, it was supposed to work like this from the start. ------------------------------------------------------------------------ [2007-03-29 13:46:03] [EMAIL PROTECTED] "It's not that lines 818-819 don't accept an array -- it's that they ONLY accept an array (because of the || instead of &&). But why test whether, if the second param IS_LONG, it is an existing ID, then ?" Ok, if you consider that passing only an integer is valid, then there is a bug in this code (the expression is wrong). However it was never thought or implemented to accept only a filter ID (to be applied to all values). filter_var or filter_input has this feature. I don't see a problem to accept this behavior (then we will have multiple ways to achieve the same goal). Here is the patch against 5.2: http://blog.thepimp.net/misc/filter_52_array_allow_id.txt I'll wait Ilia's opinion on it (we discussed this exact thing a while back), if he agrees, I'll apply the patch. Changed to feature request. ------------------------------------------------------------------------ [2007-03-29 13:03:32] exaton at free dot fr OK damn it, this typo is killing me as well. Responding to myself here : It's not that lines 818-819 don't accept an array -- it's that they ONLY accept an array (because of the || instead of &&). But why test whether, if the second param IS_LONG, it is an existing ID, then ? ------------------------------------------------------------------------ [2007-03-29 12:58:19] exaton at free dot fr Erm, fine, I can live with using filter_var() instead of filter_var_array() for this purpose, I'm not a big fan of multiple ways of doing the same thing anyway. I would like to get back to lines 818-819 of filter.c, though : "OK, so those lines say "if the second parameter (op) is a number but does not refer to an existing filter ID, ***or*** if op is not an array, then RETURN_FALSE". That should be *and*, not or ! If the second parameter is not an existing filter ID constant *and* if it is not an array, then it is not valid." ""IS_LONG && EXISTS" means: The filter ID must be an integer and the ID must exist. It accpepts array as the filter options/flags/id can be given as an array, in this case the ID validation is done later." The fact is, it /does not/ accept an array : || Z_TYPE_PP(op) != IS_ARRAY) { RETURN_FALSE; }. I.e., "if the second parameter to filter_var_array() is not an array, (forgetting whatever else has been tested just before), then return false". I say again that it should be --> && Z_TYPE_PP(op) != IS_ARRAY ... :) Pierre, Re your message at 13:55 UTC, I think that is what has been missed. ------------------------------------------------------------------------ [2007-03-29 12:55:57] [EMAIL PROTECTED] Derick, there is no bug here. Please keep it closed. Or do you have something that I missed? ------------------------------------------------------------------------ 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 http://bugs.php.net/40947 -- Edit this bug report at http://bugs.php.net/?id=40947&edit=1
