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}"
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
yohg...@ohgaki.net
