Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42299
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain macvicar.net from 193.227.246.108 cause and error)
Message-ID: <4948E2FA.4050501@macvicar.net>
Date: Wed, 17 Dec 2008 11:31:06 +0000
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: RQuadling@GoogleMail.com
CC: viroteck@viroteck.net, 
 PHP Developers Mailing List <internals@lists.php.net>
References: <494698D3.2030801@lerdorf.com>	 <bd9320b30812151009t29bc6283m79f8985022cd7e2b@mail.gmail.com>	 <10845a340812160348k18bffb0et1e75cf345b5e42cc@mail.gmail.com>	 <494797BE.3060505@macvicar.net>	 <10845a340812160606k393ddcedq5fa6a1223392c992@mail.gmail.com>	 <b19eae4e0812160707t725aa8d4j688de719061f2808@mail.gmail.com> <10845a340812170205k62a33385j14e1730fd71f0b27@mail.gmail.com>
In-Reply-To: <10845a340812170205k62a33385j14e1730fd71f0b27@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam_Report: Spam detection software, running on the system "lovelace.midden.org.uk", has
	identified this incoming email as possible spam.  The original message
	has been attached to this so you can view it (if it isn't spam) or label
	similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  Richard Quadling wrote: > 2008/12/16 Robin Burchell <viroteck@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? > [...] 
	Content analysis details:   (-4.3 points, 5.0 required)
	pts rule name              description
	---- ---------------------- --------------------------------------------------
	-1.8 ALL_TRUSTED            Passed through trusted hosts only via SMTP
	-2.6 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
	0.1 AWL                    AWL: From: address is in the auto white-list
Subject: Re: [PHP-DEV] json_encode()
From: scott@macvicar.net (Scott MacVicar)

Richard Quadling wrote:
> 2008/12/16 Robin Burchell <viroteck@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