Skip to content
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

json_pointer.contains() exceptions when path not found #1942

Closed
RobBeyer opened this issue Feb 12, 2020 · 2 comments · Fixed by #2019
Closed

json_pointer.contains() exceptions when path not found #1942

RobBeyer opened this issue Feb 12, 2020 · 2 comments · Fixed by #2019
Assignees
Labels
kind: question release item: 🐛 bug fix solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Milestone

Comments

@RobBeyer
Copy link

When using contains with a json_pointer, the expected functionality is that the contains() function will return false if the path is not found in the json object.

For a json object with "/path/[array]" this functionality operates differently, depending on the path parameter in the json_pointer.

In the case of "/path/-" the operation completes as expected, as the "-" index is beyond the end of the array (fails range check), and does not raise any error or exception (returns false).

In the case of "/path/[number]" the operation completes as expected, (returns true) if the array index is within the size() range, and (returns false) if the index is beyond the end of any array, and does not raise any error or exception.

If the object being checked in the case of "/path/[number]" does not have an array, it does not raise any error or exception (returns false).

However, in the case of "/path/string" the operation always raises an exception, as the current functionality assumes an array index, and raises an exception if it is not.

I believe that the function is presently operating counter to the intent of the contains() functionality, which is intended to verify if a given path is valid, not if the existing object can support that path.

An object should not determine how the json_pointer path is verified.
A json_pointer should be verified if it can be accessed within an object.
i.e. is object[json_pointer] valid to use? Not that the path is invalid for the object being tested.

At present the object has required that the path be an index within the array (object defined), and not that the path verifies that the json_pointer may be used to access the object.

This is present in v3.7.3.

In my option the "/path/string" access into an object with an array, should not raise an exception due to the path being checked not being a numeric index into that array.

Proposed Patch:
In bool json_pointer::contains(const BasicJsonType* ptr) const
The line:
if (JSON_HEDLEY_UNLIKELY(reference_token == "-"))
should be changed to:
if (JSON_HEDLEY_UNLIKELY((reference_token < "0") || (reference_token > "9")))
to reject any string as being an invalid index into the array.

This would therefore always return false for any non-numeric index, as any attempt to use a string to index into an array should only confirm that the json_pointer may not be used.
i.e. the json_pointer is not contained in the object.

@stale
Copy link

stale bot commented Mar 14, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Mar 14, 2020
@nlohmann nlohmann removed the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Mar 20, 2020
@stale
Copy link

stale bot commented Apr 19, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Apr 19, 2020
@stale stale bot closed this as completed Apr 26, 2020
@nlohmann nlohmann reopened this May 2, 2020
@stale stale bot removed the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label May 2, 2020
@nlohmann nlohmann added release item: 🐛 bug fix solution: proposed fix a fix for the issue has been proposed and waits for confirmation labels May 2, 2020
@nlohmann nlohmann added this to the Release 3.8.0 milestone May 2, 2020
@nlohmann nlohmann self-assigned this May 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: question release item: 🐛 bug fix solution: proposed fix a fix for the issue has been proposed and waits for confirmation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants