Bug #69187 [Asn]: json_last_error return BC in PHP7

Edit report at https://bugs.php.net/bug.php?id=69187&edit=1 ID: 69187 Updated by: bukka@php.net Reported by: hdtfonseca at gmail dot com Summary: json_last_error return BC in PHP7 Status: Assigned Type: Bug Package: JSON related Operating System: linux PHP Version: master-Git-2015-03-04 (Git) Assigned To: bukka Block user comment: N Private report: N New Comment: @nikic I think you are right. It should stay as a standard string conversion and we shouldn't have a special "hack" exceptions for specific types (null, false). I also think that we shouldn't have error for true because then we would have to have error for scalar int or float which would be unnecessary BC break. As such I think that it will be best to add just note about the conversion to the UPGRADING where is already mentioned that empty string will emit error. btw. The decoding JSON values that appear outside of object or array literals is not just a PHP extension since March 2014 when RFC 7159 became a standard (see https://tools.ietf.org/html/rfc7159#section-2 ) ;) Previous Comments: ------------------------------------------------------------------------ [2015-03-06 12:20:18] nikic@php.net @hdtfonseca: PHP also supports (as an extension to JSON - this is not supported by the standard itself) decoding JSON values that appear outside of object or array literals. E.g. it's possible to decode the string "1" to the value int(1). It just so happens that the string representation of bool(true) in PHP is "1", which is why json_decode(true) === 1 (without error). ------------------------------------------------------------------------ [2015-03-06 11:37:25] hdtfonseca at gmail dot com I think @nikic has a point. What about, TRUE, 1 and 0 values? Shouldn't they all output JSON_ERROR_SYNTAX? In PHP 5.6 they all return JSON_ERROR_NONE but I think that 1, 0, "", TRUE, FALSE and NULL should be consistent. At least "", FALSE and 0 should. ------------------------------------------------------------------------ [2015-03-06 07:23:08] nikic@php.net @bukka I think the current PHP 7 behavior is correct. The json_decode function accepts a string and is documented to accept a string. According to our coercion rules null and false correspond to the empty string "", which is rightly no longer valid. As such I don't think anything needs to change here. json_decode does not give you any guarantees that json_decode($nonString) === $nonString and I don't see why we'd want to introduce such a behavior. ------------------------------------------------------------------------ [2015-03-05 19:23:14] aharvey@php.net Well, that was embarrassing. :) Thanks for looking into this and in advance for the patch! ------------------------------------------------------------------------ [2015-03-05 18:23:46] bukka@php.net Hi Adam, this is actually caused by your commit ( https://github.com/php/php-src/commit/a7b3abe4e6f5e2fdfd8d55b676c9ca6b3f9c8cc8 ) :). The reason is the null is converted to empty string... The same will be for false. I think that it makes sense to not emit error for null or false but only for empty string. json_decode already returns number when you pass number (json_decode(1)) so it makes sense to have it consistent. There is still a small inconsistency with boolean - json_decode(false) returns NULL and json_decode(true) returns 1. However I'm not sure if it's worthy it to break BC (even slightly)... I will apply the patch for NULL and FALSE in a couple days if no objections. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=69187 -- Edit this bug report at https://bugs.php.net/bug.php?id=69187&edit=1