json_decode() should generate a syntax error when given "".
Fixes bug #68938 (json_decode() decodes empty string without error). Patch by jeremy at bat-country dot us.
- Loading branch information
- +4 −0 NEWS
- +1 −0 ext/json/json.c
- +7 −2 ext/json/tests/bug54484.phpt
- +11 −0 ext/json/tests/bug68938.phpt
| @@ -15,11 +15,16 @@ json_decode("invalid json"); | ||
| var_dump(json_last_error()); | ||
|
|
||
|
|
||
| json_decode("\001 invalid json"); | ||
This comment has been minimized.
This comment has been minimized.
LawnGnome
Author
Contributor
|
||
| var_dump(json_last_error()); | ||
|
|
||
|
|
||
| json_decode(""); | ||
| var_dump(json_last_error()); | ||
| ?> | ||
| --EXPECT-- | ||
| int(0) | ||
| int(0) | ||
| int(4) | ||
| int(0) | ||
| int(4) | ||
| int(3) | ||
| int(4) | ||
| @@ -0,0 +1,11 @@ | ||
| --TEST-- | ||
| Bug #68938 (json_decode() decodes empty string without indicating error) | ||
| --SKIPIF-- | ||
| <?php if (!extension_loaded("json")) print "skip"; ?> | ||
| --FILE-- | ||
| <?php | ||
| json_decode(""); | ||
| var_dump(json_last_error()); | ||
| ?> | ||
| --EXPECT-- | ||
| int(4) |
8 comments
on commit a7b3abe
This comment has been minimized.
This comment has been minimized.
|
This is a BC break, which should be reverted in 5.5 and 5.6 branches. |
This comment has been minimized.
This comment has been minimized.
|
One person's BC break is another person's bug fix. I think it's OK (obviously, since I committed it) — |
This comment has been minimized.
This comment has been minimized.
|
Consider this piece of code (which exists in real applications/frameworks): $data = json_decode($json);
if (json_last_error() !== JSON_ERROR_NONE) {
throw new JsonException();
}While it was completely OK to pass NULL or empty string before (e.g. I'm not arguing about empty string being valid or invalid JSON, it is clearly invalid. But this change is a BC break nevertheless. But let's see what RM thinks, cc @jpauli. |
This comment has been minimized.
This comment has been minimized.
|
On 4 Feb 2015 06:51, "Michael Moravec" ***@***.*** wrote:
Consider this piece of code (which exists in real
applications/frameworks):
$data = json_decode($json);
if (json_last_error() !== JSON_ERROR_NONE) {
throw new JsonException();
}
While it was completely OK to pass NULL or empty string before (e.g.
$json was nullable in database), now it throws an exception.
Here are some real-world examples which will break when NULL/"" is
passed: [1], [2], [3], [4], [5], [6], etc..
I'm not arguing about empty string being valid or invalid JSON, it is
clearly invalid. But this change is a BC break nevertheless.
But let's see what RM thinks, cc @jpauli.
—
Reply to this email directly or view it on GitHub.
I tend to agree with Michael. The fact is that the old parser is not
conformant anyway (see my jsond rfc for details) and it's not a good idea
to make a little bit more conformant (but still non conformant) for the
price of breaking BC in the micro release. As such I think that this should
be reverted from 5.5 and 5.6.
|
This comment has been minimized.
This comment has been minimized.
|
This breaks BC and will break applications migrating to a micro version of mature stable branches. |
This comment has been minimized.
This comment has been minimized.
|
for the record bugfixes are BC breaks by nature, and those are allowed by our rfc process. |
This comment has been minimized.
This comment has been minimized.
|
Hmm, it's still present in latest RCs, php-5.6.6RC1 and php-5.5.22RC1. :( @Tyrael: I think this change is ok for x.y+1.z as is (without E_DEPRECATED), but not for stable branches. |
This comment has been minimized.
This comment has been minimized.
|
I reverted those from our current RC , 5.5.22RC1 and 5.6.6RC1. |
@LawnGnome This is interesting one! I don't really think that this should be
JSON_ERROR_CTRL_CHARbecause the control characters are considered only for strings ( https://tools.ietf.org/html/rfc7159#section-7 ) and this is not a string as there are missing double quotes around it. The old decoder set ctrl char error but the new one (jsond based) set syntax error which makes more sense IMHO. It means a tiny BC break (if we consider errors as BC break) that I wasn't aware of. I changed the test in my PR ( bukka@c3cd2d3 ) for now and I plan to merge tomorrow. It's not a big issue that should delay the merging jsond but I'll think about it, check other cases and possibly later ping internals about it... Anyway thanks for adding this test even if it's not really related to this bug. ;)