Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60955 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 10992 invoked from network); 24 Jun 2012 12:12:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Jun 2012 12:12:53 -0000 Authentication-Results: pb1.pair.com smtp.mail=nikita.ppv@googlemail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=nikita.ppv@googlemail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.217.170 as permitted sender) X-PHP-List-Original-Sender: nikita.ppv@googlemail.com X-Host-Fingerprint: 209.85.217.170 mail-lb0-f170.google.com Received: from [209.85.217.170] ([209.85.217.170:47463] helo=mail-lb0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CC/A1-24211-34407EF4 for ; Sun, 24 Jun 2012 08:12:52 -0400 Received: by lbgc1 with SMTP id c1so6094602lbg.29 for ; Sun, 24 Jun 2012 05:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XVibX1aSnPbktuIb2NMZaDxJ7tnavBDZ66GUaniWlRk=; b=fNauLrQUn0tl7zSBOBV1mOsYn9bHh7FFuQ4k8CXlYs+MCj+GwdJh/vY4N7BzfoORaL PVpUyQ70pD+p01chsl3bv6iU59dEae32LECVHCne43j648RjhiMOeI+8WuTmFopMZyNr Vi31W3oXPoLGi6swO44p/7exbgbdrJpwZCMBuoqwdDv4BBoPE8siAGSLXPOgAZ+vb3E2 CZcre8QmEQKGBCqchnM5i5BxaEJA9p2YC6sZfAULaCE8ffl7Qp3Rn8xivBypYNhCOqJp 0L98z/ty7T50kSrJJsYkNK0/9gnGZeIJJ60UNq6GAuP5VSoX+lNr8SPll9liAMm6OcPe Avug== MIME-Version: 1.0 Received: by 10.152.105.173 with SMTP id gn13mr8411650lab.20.1340539967635; Sun, 24 Jun 2012 05:12:47 -0700 (PDT) Received: by 10.152.114.70 with HTTP; Sun, 24 Jun 2012 05:12:47 -0700 (PDT) In-Reply-To: References: <20120621141241.GA25789@analysisandsolutions.com> <4FE33EDF.2000409@lerdorf.com> <4FE61E9D.5050908@sugarcrm.com> Date: Sun, 24 Jun 2012 14:12:47 +0200 Message-ID: To: Gustavo Lopes Cc: internals@lists.php.net Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings From: nikita.ppv@googlemail.com (Nikita Popov) On Sun, Jun 24, 2012 at 12:50 AM, Gustavo Lopes wrote: > If json_encode() is not supposed to receive badly encoded data, then it's > the application writer's responsibility to make sure that the data is > correctly encoded. If, on the other hand, you think that's actually not a > error on the part of the caller to call json_encode() with badly encoded > data (i.e., just like htmlspecialchars() -- from which I removed the warning > removed in 5.4 --, json_encode() also accumulates the responsibility > validating some aspects of the input), then there's no reason to have a > warning at all. > > In other words, if it's a precondition of json_encode() that the input is > correctly encoded (and the check is just a form of safe programming), then > there's indeed an error on the part of the application writer, if it isn't, > then there's no reason for any sort of warning. > > (By the way, I'd prefer no warning at all, both for this and for inf/NAN. We > already can get the error from json_last_error() if we want to) The main problem with not throwing a warning is that it makes debugging the error quite hard. json_last_error() only gives you an error code. So you have to use some script like the one used as an example in php.net/json_last_error to figure out what the particular error code actually means. This is obviously a lot more inconvenient than simply seeing "Oh, this failed because I passed an Inf". Nikita