-
Notifications
You must be signed in to change notification settings - Fork 811
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
Marshaling into already allocated proto.Buffer stopped working #619
Comments
Replacing |
Thanks for the report. |
…en a proto.Buffer and proto.Marshal with different proto.Buffer sizes.
…. This allows us to marshal at the correct place when the buffer contains a larger backing buffer. (gogo#619)
@jrouviere |
@jmarais, Yes your branch fixes the problem I was observing. Awesome work, thanks for your quick response! |
…en a proto.Buffer and proto.Marshal with different proto.Buffer sizes.
* tests. added test case for issue (#619). Compare marshaling between a proto.Buffer and proto.Marshal with different proto.Buffer sizes. * proto/buffer. added buffer cap adjustment before giving it to marshal. This allows us to marshal at the correct place when the buffer contains a larger backing buffer. (#619) * proto/buffer. remove unsafe/reflect slice cap adjustment and rather use a full slice expression * proto/buffer. encode. add issue620 tests here * proto/buffer encode. removed unnecessary slicing. (#619) * proto/buffer. err check previously ignored error * issue619. add test package to make regenerate list
Marshalling into an already allocated
proto.Buffer
stopped working after the merge of #560.For instance:
I believe the issue is caused by the generated
XXX_Marshal
methods, which now expect the capacity of the buffer to be exactly the size of the message.The first time a
proto.Buffer
object is used its capacity will be set to the size of the message, the second time it is used, and if the message to be marshalled is smaller, the capacity stay the same and is now higher than the length of the message.The problem is that
XXX_Marshal
force the size of the buffer to its capacity (b = b[:cap(b)]
), and then truncate it back to the actual marshalled size (return b[:n], nil
), this behaviour was fine before #560.Now that we marshal backwards, the data is written at the end of the buffer (at full capacity), and XXX_Marshal returns a slice at the beginning of the buffer containing uninitialised data.
The text was updated successfully, but these errors were encountered: