Guys,
I can't keep following endless (and large) email threads about things
like that. Could you please work together on a more formal proposal
taking into consideration existing state, BC, any potential future
issues etc? If you need some guidelines, I quite like how Pythong PEPs
do it [1]. Once we have something like that in front of us, we can
evaluate it much more effectively.
Thanks.
-Andrei
[1]
http://www.python.org/dev/peps/pep-0001/#what-belongs-in-a-successful-
pep
On Aug 12, 2006, at 2:17 PM, Pierre wrote:
Hello,
> This example has nothing to do with what we are discussing here.
There
> is no conversion or detection involved here. It is a simple string
> concatenation.
And yet, the way Matt W was talking at one point, it seemed he wanted
to change that as well...
Or perhaps I misunderstood.
I still believe that the same rules should apply for type-juggling and
is_numeric, for simplicity sake.
That's not the same thing, there is no type juggling here.
>> I never actually use is_numeric, and would expect it to follow the
>> same "rules" as PHP's internal type-juggling mechanism.
>>
>> I believe leading spaces should NOT be allowed for type-juggling,
>> not
>> is_numeric, because GET/POST/COOKIE data should be subject to the
>> most
>> stringent constraints reasonable to avoid security injections.
>
> Any example?
The one above?...
http://example.com/?foo=%20.123
Is $_GET['foo'] a valid number?
I don't think it should be.
I believe it is "wrong" to allow leading/trailing spaces on numeric
data in any sort of auto-conversion or test for validity.
I was asking about a security problem. There is none. Limitatingof the
area of interest to the input filtering is not a good idea, it is very
small part of what we are talking about. I do not think arguing
endlessly about trailing/tailing spaces being valid or not will help.
This is actually a very small problem (and easy to fix).
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
