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

Workaround for MSVC's string literal compiler limit. #472

Closed
wants to merge 1 commit into from
Closed

Workaround for MSVC's string literal compiler limit. #472

wants to merge 1 commit into from

Conversation

Qartar
Copy link
Contributor

@Qartar Qartar commented Jun 7, 2015

Conventional wisdom for this issue has been "don't make proto messages that have such long descriptors" but this issue also occurs for enums that have a large number of values with relatively long names. This seems like a valid usage model.

This code escapes the entire protobuf descriptor prior to embedding. More conservative checking could be applied at the cost of code complexity.

@googlebot
Copy link

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.

@Qartar Qartar closed this Jun 7, 2015
@Qartar
Copy link
Contributor Author

Qartar commented Jun 7, 2015

Incorrect author info in commit. Resubmitting.

taoso pushed a commit to taoso/protobuf that referenced this pull request Aug 1, 2018
…d is not set (protocolbuffers#472)

Change Marshal/Unmarshal to return error if any required field is not set.

For Unmarshal, this means JSON is either missing any required field or has required field set to null.
taoso pushed a commit to taoso/protobuf that referenced this pull request Aug 1, 2018
As mentioned in protocolbuffers#509, jsonpb panics when marshaling/unmarshaling a non-generated message that has an unexported pointer field. This change will restore dynamic messages to working with jsonpb (they work fine in master; just broken in this dev branch as of protocolbuffers#472).
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.

2 participants