Handle hex escapes and other variable length escape sequences #4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fixes parsing of HL7 Hex-Escape sequences (\X....\) and other variable-length escape sequences that are not handled by the parser code. This will break with an array overflow in case escape sequences are not paired correctly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
HL7v2 messages can contain variable-length hex escapes, which are encoded as
\....\like for example in the form of Hex-Escapes (\Xabdce12\) This extends message parsing so these escape sequences are forwarded into the parsed message unchanged.In current master, the code assumes that all escape sequences are fixed-length, which e.g. parses things like
Foo\X1234\asFoo\X1234(eating the trailing escape character in the process)This MR silently fixes cases where escape sequences are unterminated by inserting a trailing escape character at the end when required. Not sure this is better than returning an error in that case.