<regex>: Limit capture groups
#4451
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
|
Will your patch fix the issue: #997 ? |
|
No, that occurs during matching. |
|
I'm speculatively mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
barcharcraz
approved these changes
Mar 7, 2024
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.
In general, the STL cannot avoid all stack overflows. (We don't know how much stack has been consumed when the user calls us, so thinking any thoughts might be too much.) However,
<regex>tries to throw exceptions instead of stack overflowing due to excessive recursion. We've had a long-standing struggle with exactly where to set this threshold during matching; right now our threshold detects most potential overflows before they happen, but not all.However, we don't do anything during regex construction. It turns out that requesting an excessive number of capture groups can easily trigger a stack overflow. We even had commented-out legacy code, indicating that our predecessors thought about this scenario somewhat. This PR adds a hardcoded limit arbitrarily set at 1000, which is more than generous enough for realistic code, yet comfortably far away from where I begin to observe stack overflows.
Alternatively, we could have more comprehensive logic to track the number of nested function calls during regex construction (which I believe would be entirely ABI-safe), but I'd like to go with this targeted change for now.