<regex>: Always reject character ranges with set limits
#5158
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
StephanTLavavej
approved these changes
Dec 2, 2024
|
Thanks for fixing this complicated control flow! 😻 I pushed minor stylistic changes and test improvements after debugging through the code and convincing myself that your changes were correct. |
|
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
|
Thanks for figuring out how this code was broken and how to fix it! 😻 🧶 🛠️ |
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.
Fixes #4995.
Unblocks libcxx test
std/re/re.regex/re.regex.construct/bad_range.pass.cpp.Note that I did not add test coverage for regular expressions like
[[.a.]-e]: After this change, this regex is rejected as well (rather than parsed incorrectly). However, such regular expressions should actually be accepted (!), because[.xxx.]is not a set of characters, but (kind of) a single character ifxxxis the name of a valid collating element. But support of collating symbols is currently so terribly broken that it is basically guaranteed to produce wrong results (see #994 (comment)), so I think it would be a major disservice to users if we actually accepted this regex without a major overhaul of collation support in the implementation.