-
Notifications
You must be signed in to change notification settings - Fork 4
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
Use lengthCode to determine whether to read sequenceLength again #101
Conversation
// dHeader for inner object not written again because the object size is already specified in the emHeader and the lengthCode of 5 allows it to not be written again | ||
writer.emHeader(true, 1, 1, 5); // pointer emHeader |
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.
is the reader supposed to be able to handle this both ways (length code ≥5 or <5)? If so, should we have another test which uses a length code <5?
(same applies to below test as well)
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 that's correct. I'll add some more tests to account for this.
// Special case can happen where the emHeader is not divisible by the typeLength and there is a remainder of 4 bytes. | ||
// 4 bytes of 0's are printed after the header length | ||
// This can happen for 8 byte typeLength types. |
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.
was this just wrong? or where is the sequence length getting read now?
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 this was just wrong because I didn't know about the lengthCode caveat. Previously I was always using emHeader size instead of sequenceLength. This case would've arisen for when the lengthCode was <5 and the object size was less than the size of the type. So there was an emHeader object size of 4 and a sequence length. Now that I'm accounting for length code, I will read the sequenceLength earlier in the array handling because the emHeaderSize isn't being used.
Does this end up also fixing FG-5301? |
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.
Nice. Btw how did you discover that this lengthCode stuff was the source of the problem?
I found an instance when the emHeader length was being used as sequenceLength when I thought that it should always print the sequenceLength in the other PR. So I looked at emheader again in the spec and found the passage above |
**User-Facing Changes** <!-- will be used as a changelog entry --> - Fix omgidl array and string reading **Description** Applies fixes in omgidl-serialization found here: foxglove/omgidl#101 Fixes: FG-5300 Fixes: FG-5301 <!-- link relevant GitHub issues --> <!-- add `docs` label if this PR requires documentation updates --> <!-- add relevant metric tracking for experimental / new features -->
Depends on: foxglove/cdr#20
In PL_CDR2 lengthCode value is used to determine whether the size specified by the emHeader can also be used as the array/string/struct length. This enables that capability.