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.Show comment
Hide comment
bukka
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.
Show comment
Hide comment
This comment has been minimized.
Majkl578
Feb 4, 2015
Contributor
This is a BC break, which should be reverted in 5.5 and 5.6 branches.
|
This is a BC break, which should be reverted in 5.5 and 5.6 branches. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
LawnGnome
Feb 4, 2015
Contributor
One person's BC break is another person's bug fix. I think it's OK (obviously, since I committed it) — "" is clearly invalid JSON, so signalling it as such seems reasonable.
|
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.
Show comment
Hide comment
This comment has been minimized.
Majkl578
Feb 4, 2015
Contributor
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.
|
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.
Show comment
Hide comment
This comment has been minimized.
bukka
Feb 4, 2015
Contributor
|
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.
Show comment
Hide comment
This comment has been minimized.
jpauli
Feb 4, 2015
Contributor
This breaks BC and will break applications migrating to a micro version of mature stable branches.
This breaks our release process and so will be reverted from our stable branches (5.5 and 5.6), and will be applied/kept in master
|
This breaks BC and will break applications migrating to a micro version of mature stable branches. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Tyrael
Feb 4, 2015
Member
for the record bugfixes are BC breaks by nature, and those are allowed by our rfc process.
but I do agree that in this specific case the bugfix isn't really that important to break applications.
for 5.5/5.6 we could maybe consider adding an E_DEPRECATED (instead setting json_globals.error_code) to indicate that this behavior will be changed/removed in the future, but previously we discussed on the list that introducing new E_DEPRECATED in a micro version isn't that nice.
|
for the record bugfixes are BC breaks by nature, and those are allowed by our rfc process. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Majkl578
Feb 6, 2015
Contributor
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.
|
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.
Show comment
Hide comment
This comment has been minimized.
jpauli
Feb 6, 2015
Contributor
I reverted those from our current RC , 5.5.22RC1 and 5.6.6RC1.
See the commit log
|
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. ;)