Richard Quadling wrote: > 2008/12/16 Robin Burchell <virot...@viroteck.net>: >> Settings which change behaviour like that aren't really all that fun >> for third party/portable applications developers, e.g. forum software >> and the likes. magic_quotes_gpc and others are good examples of this. >> >> Going back to Rasmus' mail based on his discussion with Douglas, I >> think that option #1 (documenting the way it works, and documenting >> how to do things "properly") sounds perfectly fine. > > Ok, I see. Add the optional param to the function and have a one-off > hit to the userland codebase to fix the problem. > > So is this going to be 5.3 or 6.0? > > Would you expect json_decode() to have the param as well. > > Considering json_encode() COULD encode non JSON compliant data, should > json_decode() also decode non JSON compliant data? >
I assume you always check the return value of json_decode() before you do anything with it in case of error etc. So there is no need to add a flag in my opinion to this. I have one patch that updates the parser to be more readable and add an optional depth limit to json_decode() and another patch to add flags for this. Time permitting I'll do it today. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
