Don't append invalid characters to symbol name #364
Merged
Conversation
This file contains 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
When a macro arg appears in a symbol name, the contents are appended. However, the contents of the macro arg were not being validated. Any character, regardless of whether it was allowed in a symbol name, would be appended. With this change, the contents of the macro arg are now validated character by character. The symbol name is considered to end at the last valid character. The remainder of the macro arg is treated as though it followed the symbol name in the asm source code.
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.
See #362 for details of the issue.
I fixed the problem by checking for characters in the macro arg that aren't valid symbol name characters and splitting off the rest of the macro arg at the point where the first invalid character is found.
As part of this change, I made it so that the individual token parsing functions are responsible for moving the current lexer buffer position past the current token. This allows for more flexibility and makes the code less hacky.
In particular,
ParseFixedPoint()had a hack to allow the lex buffer to only advance to the point where a second dot was found in the string. It had to move the lex buffer position backwards becauseyylex_NORMAL()would always move the position forwards bynFloatLen, which it couldn't adjust. Now it can simply move the position forwards by the correct amount instead of going backwards and then forwards.Fixes #362.