Hi Yasuo,
On Sun, Jul 26, 2015 at 9:20 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi Jakub,
>
> On Mon, Jul 27, 2015 at 3:32 AM, Jakub Zelenka <bu...@php.net> 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
> <?php
> $j = '{ "v": 0.1234567890123456789 }';
> var_dump(json_encode(json_decode($j)));
> ini_set('precision', 20);
> var_dump(json_encode(json_decode($j)));
> ?>
>
>
> string(22) "{"v":0.12345678901235}"
> string(28) "{"v":0.12345678901234567737}"
>
Yeah you will loose precision. That's just the fact that double can't
contain such a big precision. This is of course the same for serialize and
unserialize. See this example:
http://3v4l.org/nb3mE
The only difference is that that it is using different ini but you can
still change it if you want. The precision lost is the same if the values
are the same though.
>
> 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.
>
As I said I think that using preicision constant was unfortunate but start
using serialize_precision is not a win IMHO. Using serialize and
json_encoding are not the same thing. In any case this is not a bug, it's
just an unfortunate decision and we should not definitely change it in a
bug fixing release. It's a BC break. Maybe if we do an RFC, it could be
considered for 7.1 but voters will need to agree that. I'd imagine 3 voting
choices:
* keep it as it is (use precision)
* use serialize_precision
* introduce new json_precision
>
> 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.
>
you can still do ini_set('pricision', 17) resp. ini_set('pricision', 30).
>
>
> 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?
>
>
yeah but mind that the side effect of rising precision is an increasing
size of the json_encoded data which is not what everyone is happy with...
Cheers
Jakub
