Skip to content

Report an error for over-large repetition counts instead of a literal (#663) - #670

Open
xhon-pelushi wants to merge 1 commit into
google:mainfrom
xhon-pelushi:fix-663-repetition-overflow
Open

xhon-pelushi wants to merge 1 commit into
google:mainfrom
xhon-pelushi:fix-663-repetition-overflow

Conversation

@xhon-pelushi

Copy link
Copy Markdown

Problem

a{1000000000} parses successfully (as the literal string a{1000000000}), while smaller over-limit counts like a{10000} correctly fail with "invalid repetition size" (#663). The maximum repetition count is 1000, so both should error.

ParseInteger() (re2/parse.cc) bails out mid-number to avoid overflow:

while (digit) {
    if (n >= 100000000)
        return false;        // stops before consuming all the digits
    n = n*10 + c - '0';
    ...
}

Returning false makes MaybeParseRepetition() fail, so { is treated as a literal instead of a repetition — the count never reaches the maximum_repeat_count check in PushRepetition().

Fix

Keep consuming the digits and cap the accumulated value instead of bailing out, so the repetition is still recognized and then rejected as too large:

while (digit) {
    if (n < 100000000)
        n = n*10 + c - '0';  // cap (avoids overflow), keep consuming
    ...
}

n is bounded at < 1e9 (well within int), and PushRepetition() rejects any min/max > 1000 with kRegexpRepeatSize, so a{1000000000} now reports "invalid repetition size" like the other over-limit counts. Values at or below the limit are unaffected.

Test

Adds a{1000000000} and a{0,1000000000} (high position of the range) to badtests[] in re2/testing/parse_test.cc, which asserts Regexp::Parse(...) == NULL. Both currently parse as literals (so the test fails on main) and error with this change.

Fixes #663

ParseInteger() stopped mid-number once the accumulated value reached 1e8 and
returned false. For a repetition like {1000000000} that made
MaybeParseRepetition() return false, so the '{' was treated as a literal and
the whole pattern parsed successfully -- even though smaller over-limit counts
such as {10000} correctly report "invalid repetition size".

Keep consuming the digits and cap the accumulated value instead of bailing out,
so the repetition is recognized and PushRepetition() rejects it as too large,
consistent with other counts above the limit.

Adds a{1000000000} and a{0,1000000000} to the parser badtests.

Fixes google#663

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Potential inconsistency in handling the maximum repetition size

1 participant