Fixes #1675 - T1 eexec end finding spec compliance #1676
Merged
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
The T1 spec (https://www-cdf.fnal.gov/offline/PostScript/T1_SPEC.PDF) on page 14 says that: > The text encrypted by eexec must be followed by 512 ASCII zeros. There may be > white space characters (blank, tab, carriage return or line feed) > interspersed among these zeros. * Add a failing test case with white space characters interspersed among the trailing zeros after the eexec * Fix eexec end finding so that it passes this new test case
justvanrossum
approved these changes
Aug 1, 2019
justvanrossum
requested changes
Aug 1, 2019
justvanrossum
approved these changes
Aug 1, 2019
|
Thanks for addressing this so quickly 😁 |
|
Thanks for your contribution! 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The T1 spec (https://www-cdf.fnal.gov/offline/PostScript/T1_SPEC.PDF) on
page 14 says that:
Add a failing test case with white space characters interspersed
among the trailing zeros after the eexec
Fix eexec end finding so that it passes this new test case
This modification to the method for finding the end of the eexec section is more robust than the current method (which looks for 64 consecutive ASCII
0s immediately after the encrypted text ends) as it handles the spec's allowance for arbitrary interspersed whitespace. A regex was convenient here (and was already used infindEncryptedChunks), but it could be unrolled into a function if need be.While more robust than the existing function, it's unclear to me how the spec would handle an eexec section that coincidentally has 512 ASCII
0s in the middle of it (or any combination of that with interspersed whitespace). This approach does not handle that, but neither does the existing solution.