Skip to content

Implement parsing of hexadecimal Unicode characters from JSON #4590

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

Merged

Conversation

antlechner
Copy link
Contributor

Previously, if a JSON file contained a string in hexadecimal Unicode representation, e.g. "\u0001", the JSON parser would discard the "\u" part and store the string as (the four-character string) "0001". This PR fixes this so the resulting string is equal to (the one-character string) "\u0001".

  • Each commit message has a non-empty body, explaining why the change was made.
  • n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
  • n/a My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

Copy link
Collaborator

@tautschnig tautschnig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cpplint and clang-format both have formatting complaints, otherwise looks good.

Previously, if a JSON file contained a string in hexadecimal Unicode
representation, e.g. "\u0001", the JSON parser would discard the "\u"
part and store the string as "0001". This commit fixes this so the
resulting string is equal to "\u0001".
@antlechner antlechner force-pushed the antonia/json-parsing-unicode branch from ff7234d to 06e666b Compare April 30, 2019 10:05
@antlechner antlechner merged commit 0e16cbb into diffblue:develop Apr 30, 2019
@antlechner antlechner deleted the antonia/json-parsing-unicode branch April 30, 2019 10:54
{
// Character in hexadecimal Unicode representation, in the format
// \uABCD, i.e. the following four digits are part of this character.
assert(p + 4 < yyjsontext + len - 1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest p + 5 < yyjsontext + len would be better -- we're checking for 5-byte string uXXXX being in range, after all

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found the current version to be clearer: when pointing to u, if you advance by four steps (pointing to the last hex character), then you have to still be to the left of the last " of the string. But I'm happy to change it in a follow-up PR if you think your version is more intuitive.

assert(p + 4 < yyjsontext + len - 1);
std::string hex(++p, 4);
result += std::stoi(hex, nullptr, 16);
p += 3;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment that you're intentionally leaving p pointing to the last char of the escape

// \uABCD, i.e. the following four digits are part of this character.
assert(p + 4 < yyjsontext + len - 1);
std::string hex(++p, 4);
result += std::stoi(hex, nullptr, 16);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this casts to a char (8-bit uint), so will only work for unicode characters <= 255

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is addressed in a follow-up PR: #4594

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants