Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87305 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22062 invoked from network); 26 Jul 2015 20:21:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Jul 2015 20:21:23 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.179 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.160.179 mail-yk0-f179.google.com Received: from [209.85.160.179] ([209.85.160.179:35647] helo=mail-yk0-f179.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1B/A2-06606-04145B55 for ; Sun, 26 Jul 2015 16:21:21 -0400 Received: by ykdu72 with SMTP id u72so55114956ykd.2 for ; Sun, 26 Jul 2015 13:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=FE3IH05J/06Xgt/R2964jeCH4hRMyigsCrue6uYTvhU=; b=I/uwnjjeRD2gGNITQg4tcCvO+l4iHh8MqxYfoF6DzrhG7+dGbNoLM0ApACZy1q7OMy OdM+efyEwnmUcyiRYkgDgX0sgjhiY1JGkAOYLnuUAwEA8CfH870ZPurEBWSF/W8k4NiT HxPftjIwv7PwXAvD7YioRcbMX40vkFr2lIcD11Gkmi7w1auy2zgkfF3n59vzJkmdYost KXX7VvI2Ho9HIm2QWc4raQAhbhjXmx1IdnxHoOVYiiOtk3XR9U9yfB9vnb9eowPoCehP /amKCYb+0jcO1J3xNvDCG1ORMubBIFNcM6/+7bP+hYxoU8POinjxi3asS9JLmYKBW9sK kQjg== X-Received: by 10.170.207.195 with SMTP id y186mr26624176yke.2.1437942078002; Sun, 26 Jul 2015 13:21:18 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.129.40.77 with HTTP; Sun, 26 Jul 2015 13:20:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Jul 2015 05:20:38 +0900 X-Google-Sender-Auth: qgg7zCZEYnbHAHuqGP3vMeztIH0 Message-ID: To: Jakub Zelenka Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a1139e11cc45c38051bccfa92 Subject: Re: [PHP-DEV] json_decode/encode should return full precision values by default From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a1139e11cc45c38051bccfa92 Content-Type: text/plain; charset=UTF-8 Hi Jakub, On Mon, Jul 27, 2015 at 3:32 AM, Jakub Zelenka wrote: > I don't think that this is a bug. Your example is also completely > unrelated to json because the place when the value is rounded is var_dump > where it's based on ini precision. You would get the same values with > json_encode but it's only because it uses the same ini ( precision ). > Basically it has nothing to do with json_decode. > OK. Better example. [yohgaki@dev PHP-master]$ ./php-bin string(22) "{"v":0.12345678901235}" string(28) "{"v":0.12345678901234567737}" I see that that the bug report you created ( > https://bugs.php.net/bug.php?id=70137 ) is actually about using > serialize.precision instead of precision in json_encode . I agree that > using 'precision' ini is not the best solution. However I don't think that > start suddenly using serialize.precision is a good idea. First of all it's > a big BC break that will be quite difficult to find (There is no way this > should go to the point release because this is changing the generated > json). Also the json encode usage is much wider than serialization. There > might be use cases when you don't care about maximal precision and you > prefer to save some space. Imagine that you are transferring lots of float > numbers. Then it will result in increasing of the transfer size. It would > be great if the new ini was used when it was introduced but I'm afraid that > changing that now is not a good idea > > I think that due to BC break, this shouldn't be changed. If you really > want a bigger precision, you can do ini_set('precision', 30) before > json_encode and then set it back. It means that this not a bug because you > can still change it if you want. That means that we can't change before PHP > 8 or whatever comes after 7... :) > Same argument could be done for serialize, but it's changed to keep more precise value. Manual recommend json_decode/encode for data serialization also. Warning Do not pass untrusted user input to unserialize(). Unserialization can result in code being loaded and executed due to object instantiation and autoloading, and a malicious user may be able to exploit this. Use a safe, standard data interchange format such as JSON (via json_decode() and json_encode()) if you need to pass serialized data to the user. http://jp2.php.net/manual/en/function.unserialize.php It does not make sense having different serialization for float. Losing effective precision is design bug. IMHO. Currently users cannot handle even Google Map JSON data correctly by default. Fixing this is just a matter of using serialize.precision. If users need larger setting than 17 for whatever reason, they may do ini_set('serialize.precision', 30) and the rest of codes are unaffected. BTW, larger precision setting does not mean precise, but current behavior definitely lose effective values. Those who don't care for precise data handling wouldn't care for more precise data handling, do they? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a1139e11cc45c38051bccfa92--