Summary

A Regexp keeps its state in two independent places: the @source/@flags IVs, and the compiled pattern behind DATA_PTR. Only Regexp.new set both, so every other way of producing a Regexp left the pair out of step. dup and clone gave back a Regexp that answered every reader correctly and matched nothing, and Regexp.allocate gave the readers a nil @source that mrb_str_cat_str() dereferenced as an RString.

Changes

dup and clone

Regexp defined no initialize_copy, and the compiled pattern is not part of what mrb_iv_copy() carries over. It cannot be: one mrb_regexp_pattern is owned by one object and freed with it, so a copy holding the original's pointer would hand regexp_free() the same block twice. The copy therefore kept @source and @flags and nothing else:

r = /ab(c)/i
r.dup.source         # => "ab(c)"          (correct)
r.dup.to_s           # => "(?i-mx:ab(c))"  (correct)
r.dup == r           # => true             (correct)
r.dup.match?("ABC")  # mruby: TypeError    CRuby: true

Every matcher raised TypeError on the NULL DATA_PTR. A valid Regexp became unusable, and silently: every reader kept answering correctly, so nothing but an actual match told you.

Regexp#initialize_copy compiles the copy's own pattern from the same source and flags, which is what CRuby's rb_reg_init_copy() does. The body regexp_init() already had is factored out as re_initialize() so the two entry points cannot drift apart in what they leave behind, and an original with no source is refused where the copy would be compiled from it, as CRuby refuses Regexp.allocate.dup.

The capture-name table is part of what the compile leaves behind, and mrb_iv_copy() runs before initialize_copy(), so a pattern that names nothing takes away the table the copy arrived holding. Without that, a copy of an original whose @source was replaced with a pattern naming nothing would answer names and named_captures with names its own pattern cannot resolve, which MatchData#[] then refuses.

The readers on an uninitialized Regexp

Regexp.allocate is on every class and hands out an object that never went through the initializer: no @source, no @flags, a NULL DATA_PTR. The matchers already refused it through DATA_GET_PTR(), but the readers did not. to_s and inspect passed the nil @source to mrb_str_cat_str() and Regexp.new(re) passed it to RSTRING_PTR(), both of which take an RString and dereference it as one; all three segfaulted. source, options, casefold?, names, named_captures, hash and == answered from state that was never set.

A single re_check_initialized() raises TypeError, "uninitialized Regexp", which is where CRuby's rb_reg_check() sits and what it raises. Two readers answer instead of raising, as CRuby does: inspect prints the default #<Regexp:0x...> form, so the object stays displayable in a backtrace or a debugger, which is where it is most likely to be met, and it falls back on the same pair the guard raises on, so a written or inherited @source with no pattern behind it prints that form too, as rb_reg_inspect() does by testing the pattern for itself; and == answers identity, and a non-Regexp, before either source is read.

The guard tests DATA_PTR and the type of @source, and the two halves answer different questions. DATA_PTR is what says the object was initialized: only re_initialize() writes it, no copy carries it, and no IV write can forge it. @source on its own would not say that, being an ordinary IV, and two objects that never reached the initializer would still answer through it: a copy from a subclass that overrides initialize_copy without calling super, which inherits the source and no pattern, and an allocated Regexp with a source written onto it. The @source type check is the other half, covering the value that mrb_str_cat_str() and RSTRING_PTR() dereference as an RString, which DATA_PTR says nothing about; dropping it would put r.instance_variable_set(:@source, nil); r.to_s back on the crashing path.

names and named_captures live in mrblib, where DATA_PTR cannot be seen, so they reach the same guard through a private __check_initialized rather than testing @source from Ruby.

Behaviour

Every row was run against CRuby 4.0.6, and the after column matches it except the last. There Regexp.new sets the IVs before it compiles, so the object keeps a source and goes on answering source, options, casefold?, names, named_captures, hash, inspect, to_s and == from it while the matchers refuse it; CRuby raises TypeError from all of them, because it never gets as far as writing anything onto the object. That is what the initializer's own comment already describes, it is not one of the out-of-step paths this closes, and changing it is a separate question, so it is left as it is and pinned by a test.

Two divergences from CRuby remain, both pre-existing and outside this change. The matchers report uninitialized Regexp (expected Regexp) where CRuby says uninitialized Regexp; the class and the reason are the same and only the wording differs, since the text comes from DATA_GET_PTR(). And {Regexp.allocate => 1} succeeds because mruby's small-hash linear scan never calls hash for any object, which is not Regexp-specific.

Size

bin/mruby .text under build_config/ci/gcc-clang.rb, both sides built at the same path from an empty build directory. The figures predate the mrb_iv_remove() in re_initialize() and the DATA_PTR test in inspect, which are not in them.

All of it is regexp.o's .text (27,413 → 28,645 in the bintest build). By function: regexp_init_copy() is +497 and the re_initialize() split is +352 against regexp_init()'s -278, which is the code actually added; the seven C readers take +23 to +79 each for the guard, which -O3 inlines at every call site and -O0 does not, and that is the gap between the two figures above. gem_init.o's .rodata grows 16 bytes for the two __check_initialized calls compiled into mrblib, which is outside .text.

Testing

• rake -m test on each of the two commits (host, default gembox, clang): 2336 and 2338 tests, 0 KO, 0 crash, 0 warning; bintest 128, 0 KO.
• MRUBY_CONFIG=clang-asan rake -m test (ASan + UBSan, full-core gembox): 2577 tests, 0 KO, 0 crash, 0 warning; bintest 101, 0 KO.
• Under that same ASan build with detect_leaks=1, three scripts, all clean and none reporting:
  • every Regexp method against Regexp.allocate, 50 methods across 30 argument shapes, plus 36 external entry points (String#gsub/sub/split/scan/index/match/[]/partition, Symbol#match, Array#grep, case/when, interpolation, Hash keys, dup/clone);
  • 2000 dup/clone copies with interleaved GC.start, each copy matching through its own pattern, the originals outliving the copies and the copies outliving the originals;
  • 702 calls against a valid Regexp whose @source, @flags or @named_captures was overwritten with nil, integers, symbols, arrays, hashes, floats, booleans and plain objects, running the readers, the matchers and the copies against the result.
• The before column of the table above reproduced on master: Regexp.allocate.to_s, .inspect and Regexp.new(Regexp.allocate) each exit 139, and /ab(c)/i.dup answers source with "ab(c)" while match? raises.

Environment

The ## Size builds, as src/string.o.flags recorded them (-MMD -c, -I and -o dropped):

# bintest
gcc -std=gnu99 -g -O3 -Wall -Wundef -Werror-implicit-function-declaration -Wwrite-strings -DMRB_GC_FIXED_ARENA -DMRB_USE_BIGINT -DMRB_USE_COMPLEX -DHAVE_MRUBY_ENCODING_GEM -DMRB_UTF8_STRING -DHAVE_MRUBY_IO_GEM -DMRB_USE_RATIONAL -DHAVE_MRUBY_REGEXP_GEM -DMRB_USE_SET -DMRB_USE_TASK_SCHEDULER -DMRB_USE_DEBUG_HOOK

# ascii-ctype
gcc -std=gnu99 -g -O3 -Wall -Wundef -Werror-implicit-function-declaration -Wwrite-strings -DMRB_USE_ASCII_CTYPE -DMRB_USE_BIGINT -DMRB_USE_COMPLEX -DHAVE_MRUBY_ENCODING_GEM -DMRB_UTF8_STRING -DHAVE_MRUBY_IO_GEM -DMRB_USE_RATIONAL -DHAVE_MRUBY_REGEXP_GEM -DMRB_USE_SET -DMRB_USE_TASK_SCHEDULER

# byte-string
gcc -std=gnu99 -g -O3 -Wall -Wundef -Werror-implicit-function-declaration -Wwrite-strings -DMRB_USE_BIGINT -DMRB_USE_COMPLEX -DHAVE_MRUBY_IO_GEM -DMRB_USE_RATIONAL -DHAVE_MRUBY_REGEXP_GEM -DMRB_USE_SET -DMRB_USE_TASK_SCHEDULER

# cxx_abi
gcc -g -O3 -Wall -Wundef -Wwrite-strings -x c++ -std=gnu++03 -DMRB_GC_FIXED_ARENA -DMRB_USE_CXX_EXCEPTION -DMRB_USE_CXX_ABI -DMRB_USE_BIGINT -DMRB_USE_COMPLEX -DHAVE_MRUBY_ENCODING_GEM -DMRB_UTF8_STRING -DHAVE_MRUBY_IO_GEM -DMRB_USE_RATIONAL -DHAVE_MRUBY_REGEXP_GEM -DMRB_USE_SET -DMRB_USE_TASK_SCHEDULER

# full-debug
gcc -std=gnu99 -g -O3 -Wall -Wundef -Werror-implicit-function-declaration -Wwrite-strings -g3 -O0 -DMRB_GC_STRESS -DMRB_USE_DEBUG_HOOK -DMRB_DEBUG -DMRB_USE_BIGINT -DMRB_USE_COMPLEX -DHAVE_MRUBY_ENCODING_GEM -DMRB_UTF8_STRING -DHAVE_MRUBY_IO_GEM -DMRB_USE_RATIONAL -DHAVE_MRUBY_REGEXP_GEM -DMRB_USE_SET -DMRB_USE_TASK_SCHEDULER

Summary by CodeRabbit

• Bug Fixes
  • Regular expression objects that were not properly initialized now consistently raise a clear error when accessed.
  • Duplication and cloning now produce fully functional, independent regular expression objects.
  • Comparisons, hashing, pattern inspection, and matching behave reliably for invalid or partially initialized expressions.
  • Inspection of uninitialized expressions now safely displays a default representation.