-
Notifications
You must be signed in to change notification settings - Fork 7.9k
RFC - json_validate() #9399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC - json_validate() #9399
Conversation
Hello @bukka. Here is my new PR, I changed the name of the function to json_validate as you were the 3rd person suggesting that name actually 👍 Honestly, I can go further with the code, but I would have to touch more the parser, and you mentioned that I should stay away from json_decode the more that I could. What I had in mind (but I did not do it) was to move out all hooks that the parser could trigger, out of the parser itself, into a different place; giving the developer the chance to re-use the parser with custom function hooks, but doing so would involve move things to different places, and I though that doing something like that would affect negatively my RFC; at the end, is the functionality what I car more about. Anyway, hopefully, this is in the direction you suggested me. I don't mind changing the code as many times as needed, seriously. Thanks in advance, and I will wait for your reply. PD: I will keep the PR as Draft, and keep the commits also, until the moment to squash comes. |
Whenever you can, can you give me a feedback about this? Thanks in advance 😄 PD:
|
It looks good to me for the RFC purpose. There are some minor things that we can iron out if the RFC gets accepted but otherwise it's fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, certainly good enough to proceed with the RFC process. Thank you!
ext/json/json.c
Outdated
} | ||
|
||
if (!(options & PHP_JSON_THROW_ON_ERROR)) { | ||
JSON_G(error_code) = PHP_JSON_ERROR_NONE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're setting the error_code
here, but wouldn't it make more sense to return this value from the function? That would mean that instead of returning a boolean, it would have to be an integer, with 0
likely having to mean no error
, but that is not something that is unheard of.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to say that returning a boolean was my personal preferred approach. If you think we should do it with the int way, let me know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have being thinking, and I really prefer returning bool, and being able to call json_last_error() to find out what happened
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wrote this down in the RFC as an open question
ext/json/json.c
Outdated
if (php_json_yyparse(&parser)) { | ||
php_json_error_code error_code = php_json_parser_error_code(&parser); | ||
if (!(options & PHP_JSON_THROW_ON_ERROR)) { | ||
JSON_G(error_code) = error_code; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A validation routine should not have side effects, such as setting a global error_code
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will check this and will be back to you
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@derickr
The reason I kept that code, was because of the usage of json_last_error() function.
I , and other developers in the mailing list find it useful to have such information, to know why a validation failed so we can have messages like:
- Malformed UTF-8 characters, possibly incorrectly encoded
- Syntax error
- Maximum stack depth exceeded
etc.
I think is good thing to have, also some other devs from mailing list.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a legit solution; an alternative could be to return the error code as int (instead of a bool).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wrote this down in the RFC as an open question
I Will update tomorrow with all reviews |
@bukka I already pushed a change your review. Can you take a look at the change again? |
@TysonAndre @bukka wow!!!!! Thanks for such a feedback,I will make the changes later today, traveling at the moment |
Thanks in advance, hopefully I got the comments in the right way. .... at least the automatic tests are green |
@bukka @TysonAndre @cmb69 , RFC Accepted! 🥳 Should I squeeze the commits on this PR to one? Is there anything else I should do besides updating the RFC as stated in step 7.1 of the RFC process? RFC How-To |
You should likely send another email to the list, mentioning that the vote finished and summarizing the voting results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any issues, the implementation looks correct. One optional style nit on the bit flag check.
ZEND_PARSE_PARAMETERS_END(); | ||
|
||
|
||
if ((options != 0) && (options != PHP_JSON_INVALID_UTF8_IGNORE)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if ((options != 0) && (options != PHP_JSON_INVALID_UTF8_IGNORE)) { | |
if (options & ~PHP_JSON_INVALID_UTF8_IGNORE) { |
this works, but checking for any bits found in bitwise not in allowed flags is shorter and conventional - it also works and is used for combinations of multiple flags
@TysonAndre Will you also make the NEWS/UPGRADING changes? |
@juan-morales do you plan to add a new php.net manual page for this new function? I would like to add support for it in PHPStan and was wondering which JSON flags are supported |
Based off my experience with PHP 8.2, the manual pages are written “in bulk” based off the UPGRADING notes once the release comes nearer. See: php/doc-en#1803
Only |
Greetings, I have a small corner case I don't think gets addressed here, what if we have json object where same key is used two times, php json_decode would just overwrite it and leave the last in the order, but JAVA for example would throw an error as the json is not valid. I do think it is okey that PHP still can parse it, and json_decode remains silent on an issue in a way, but possibly a function that is validating my json should be giving me information about it. What do you think guys? |
Hello @marksgerasimovs , thanks for the message. |
JSON.parse('""'); It returns an empty string, which is consistent with PHP's |
@Ayesh |
Remember, in this context a "valid JSON" is a JSON valid for |
An empty string ( |
https://wiki.php.net/rfc/json_validate