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

Edit report at https://bugs.php.net/bug.php?id=69187&edit=1 ID: 69187 Comment 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: Yes this is correct. The reason for that is type casting. You could write it as: (string) NULL === "" (string) FALSE === "" (string) TRUE === "1" (string) 0 === "0" (string) 1 === "1" Nikic has a strong point that the json_decode is documented with first argument "string $json" and as such we should follow ZPP casting rules in that case. It makes sense IMHO as it will be consistent with most internal functions. I have updated UPGRADING in https://github.com/php/php-src/commit/9d037d574cc359405c7a818c2235644633705999 Previous Comments: ------------------------------------------------------------------------ [2015-03-06 13:48:48] hdtfonseca at gmail dot com Let's see if I got this. NULL will return 4 "" will return 4 FALSE will return 4 TRUE will return 0 0 will return 0 1 will return 0 If I'm correct, I think that FALSE should return 0 instead. (I'm creating a little test for this if you don't mind) ------------------------------------------------------------------------ [2015-03-06 12:53:17] bukka@php.net @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 ) ;) ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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