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

Use lengthCode to determine whether to read sequenceLength again #101

Merged
merged 3 commits into from
Nov 16, 2023

Conversation

snosenzo
Copy link
Collaborator

@snosenzo snosenzo commented Nov 14, 2023

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.
image

@snosenzo snosenzo requested a review from jtbandes November 14, 2023 22:21
@snosenzo snosenzo requested a review from achim-k November 15, 2023 16:18
Comment on lines +495 to +496
// 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
Copy link
Member

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)

Copy link
Collaborator Author

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.

Comment on lines -264 to -266
// 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.
Copy link
Member

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?

Copy link
Collaborator Author

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.

@jtbandes
Copy link
Member

Does this end up also fixing FG-5301?

@snosenzo snosenzo marked this pull request as ready for review November 16, 2023 17:16
Copy link
Member

@jtbandes jtbandes left a 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?

@snosenzo
Copy link
Collaborator Author

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

@snosenzo snosenzo merged commit bb21d5e into main Nov 16, 2023
@snosenzo snosenzo deleted the lengthcode-array-length branch November 16, 2023 19:42
pezy pushed a commit to pezy/studio that referenced this pull request Sep 14, 2024
**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 -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants