With a subexp call, the result of unset_addr_list_fix overwrote the error, so a pattern over the limit compiled without raising RegexpError.
Follow-up to cf35145fc4.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit 16d8a554b2)
Concatenated large repeats reach a program past INT_MAX from a few hundred
kilobytes of source, and the offsets emitted into it wrap. Cap the size
while the program is emitted, which does not depend on the length pass that
overflows along with it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(cherry picked from commit cf35145fc4)
Nested bounded repeats let the int product tlen * qn->lower overflow, so
the check that keeps the compiler from unrolling a large repeat could pass
for an enormous one, hanging the compile or emitting wrapped jump offsets.
Compare against the limit by division instead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit 7cfe8dc82f)
Add explicit errors for excessive range-repeat and null-check IDs;
map new errors in regerror; add regression tests for oversized generated
patterns.
(cherry picked from commit 493d26dcde)
Clear all refined CCs on reopening refinement mod
In cfd7729ce7 we started using inline
caches for refinements. However, we weren't clearing inline caches when
defined on a reopened refinement module.
Fixes [Bug #20246]
Fix [Bug #20246]: Don't set next_head_exact if a capture is called (#9897)
According to the C99 specification section 7.20.3.2 paragraph 2:
> If ptr is a null pointer, no action occurs.
So we do not need to check that the pointer is a null pointer.
* regcomp.c (print_indent_tree): make a function for debug static.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@57420 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* regcomp.c (get_min_match_length): Fix compile error with old version
of fcc (Fujitsu C Compiler) on Solaris 10. [Bug #13059][ruby-dev:49909]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@57143 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* meta character \X matches Unicode 9.0.0 characters with some workarounds
for UTR #51 Unicode Emoji, Version 4.0 emoji zwj sequences.
[Feature #12831] [ruby-core:77586]
The term "character" can have many meanings bytes, codepoints, combined
characters, and so on. "grapheme cluster" is highest one of such words,
which means user-perceived characters.
Unicode Standard Annex #29 UNICODE TEXT SEGMENTATION specifies how to
handle grapheme clusters (extended grapheme cluster).
But some specs aren't updated to current situation because Unicode Emoji
is rapidly extended without well definition.
It breaks the precondition of UTR#29 "Grapheme cluster boundaries can be
easily tested by looking at immediately adjacent characters". (the
sentence will be removed in the next version)
Though some of its detail are described in Unicode Technical Report #51
UNICODE EMOJI but it is not merged into UTR#29 yet.
http://unicode.org/reports/tr29/http://unicode.org/reports/tr51/http://unicode.org/Public/emoji/4.0/
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@56949 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Ruby's Regexp doesn't allow normal numbered groups if the regexp
has named groups. On such case it optimizes out related NT_ENCLOSE.
But even on the case it can use \g<0>.
This fix not to remove NT_ENCLOSE whose regnum is 0.
[ruby-core:75828] [Bug #12454]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@55562 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
[bug] fix problem with optimization of \z (Issue #16) [Bug #8210]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@40276 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
children bug. patched by Suraj Kurapati. [ruby-core:40964]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@33754 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Hiroshi SHIBATA