Hi! > Programmers haven't figured out how to use the 1-2 covering functions > that already exist and you expect them to do it in userland code?
I expect them to use libraries. I don't think anything that is written in PHP means it's wrong and has to be rewritten in C. > Maybe we should ditch json_encode() tomorrow. I can do it in userland > code too. PHP does a LOT of things possible in userland code. The > argument I made in the RFC boils down to simply giving programmers a > helping hand. They are writing insecure code because PHP isn't > fulfilling that need for one of the most serious security risks in PHP > today. Surely that warrants action to serve programmers? We already have basic functions that do that, and we have extension that does that. If you need more, I'm not sure you should do it in C. If you do just the same under a different name, I don't think it should be done at all. > encoding. That's 2 versus the list of flaws in htmlspecialchars() I > blogged about (the link is in the RFC) and whatever might > theoretically exist if PHP actually had Javascript and CSS options. I think the approach of creating third data filtering API (plain functions, filter, and now this) in PHP core is wrong. I do not see why the same functions can not be (in case of CSS) or already are not (in case of most others) implemented in existing functionality. If the whole question is that people don't know which one to use in which context, creating an entirely new core API does not sound like a good solution to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
