mruby-regexp: stop truncating a group name to a uint16_t - #7007

Split out of #7002 rather than folded into it. That pull request fixed a heap-buffer-overflow
read in MatchData#[] for an over-long group name, and closed it with a one-line bound on the
requested length. This one is the compile side of the same uint16_t: entirely in bounds, and
entirely a compatibility bug. #7002 said the compile-side truncation was consistent and not
worth a guard of its own, which was right about the memory safety and wrong about the
behaviour.

re_named_capture::name_len was a uint16_t, and compile_atom() narrowed to it with a cast
rather than rejecting the name. The truncation was silent, and every reader worked from the
truncated bytes, so nothing read out of bounds: the arena was built from the same truncated
lengths every reader used. What was lost was the rest of the name, and with it the identity of
the group.

n = "A" * 65539
re = Regexp.new("(?<#{n}>x)")
re.named_captures.keys.map(&:length)
# CRuby: [65539]
# mruby: [3]

re.match("x")[n]
# CRuby: "x"
# mruby: IndexError

re.match("x")["AAA"]
# CRuby: IndexError
# mruby: "x"

The group existed and matched, but it could not be reached by the name it was given, and it
answered to a three-byte name that appeared nowhere in the pattern.

Two consumers disagreed about the same name

The truncation also let two groups collapse onto one stored name, and the two APIs that
resolve a name then picked different groups.

long = "ab" + "A" * 65536              # length 65538, (uint16_t)65538 == 2
re = Regexp.new("(?<ab>x)(?<#{long}>y)")
md = re.match("xy")

md["ab"]
# mruby: "x", group 1

md.named_captures
# mruby: {"ab" => "y"}, group 2

MatchData#[] scans the table and stops at the first entry, so "ab" resolved to group 1.
Regexp#named_captures and MatchData#named_captures build a Hash and let the later entry
overwrite the earlier one, so the same name resolved to group 2. One name, two answers, in one
pattern.

\k<name> bound to the wrong group

The same collapse reached the matcher, where it changed what the pattern accepts.

long = "ab" + "A" * 65536
re = Regexp.new("(?<ab>x)(?<#{long}>y)\\k<#{long}>")

re.match("xyx")
# CRuby: nil
# mruby: matches

re.match("xyy")
# CRuby: matches
# mruby: nil

The backreference was written against the second group and bound to the first. That is a wrong
answer from a pattern that compiled without complaint, not a diagnostic gap.

A name of exactly 65536 bytes became the empty name

(uint16_t)65536 == 0, so the name was truncated away entirely and the group answered to "".

z = "Z" * 65536
re = Regexp.new("(?<#{z}>x)")
re.named_captures.keys.map(&:length)
# CRuby: [65536]
# mruby: [0]

re.match("x")[""]
# CRuby: IndexError
# mruby: "x"

What this changes

re_named_capture::name_len is a uint32_t, and the locals, loop counters and comparisons
that consume it follow. Every answer above now matches CRuby.

The alternative was to reject a name that does not fit, which is two lines and no
representation change. It was not taken because the limit is not one the design needs. The
gem's other uint16_t limits are structural: RE_MAX_CAPTURES is 32 because two functions in
regexp.c hold int last_captures[RE_MAX_CAPTURES * 2] on the stack, and re_inst.offset
sizes every instruction. A name's length is neither. On a 64-bit target the struct is unchanged
at 16 bytes, since const char *name; uint16_t name_len; uint16_t group; already padded to
that, and on a 32-bit target the entry grows from 8 bytes to 12. Trading four wrong answers for
that seemed the better side of the deal.

The bound the cast needs does not go away with the wider field. c->p - cap_name is a
ptrdiff_t over the pattern source and nothing limits the pattern's length, so a check has to
sit in front of the cast whatever the field's width is. It moves to UINT32_MAX, out of reach
of any pattern this gem can compile, and it is what keeps the cast lossless.

RE_MAX_NAME_LEN spells that bound once, beside the field it describes, so a later change of
width is one line. RE_NAME_LEN_FITS() widens to uintmax_t before comparing, which is not
cosmetic: on a target whose argument type is no wider than the field, a ptrdiff_t on ILP32 or
an mrb_int on MRB_INT32, the naive comparison is against a constant the type cannot exceed,
and clang reports it.

warning: comparison of integers of different signs: 'int32_t' (aka 'int')
         and 'unsigned int' [-Wsign-compare]

uintmax_t rather than uint64_t because C99 makes the exact-width 64-bit types optional and
every uint64_t in mruby today sits behind MRB_GC_PROFILE or MRB_INT64.

The guard #7002 added to matchdata_aref() stays, now reading through the same macro. It is
what makes the cast on the line below it lossless, and dropping it would put a truncating
comparison back next to an untruncated memcmp(), one edit away from the same overread.

Testing

• rake test on the host build: 1942 total, 1924 OK, 0 KO, 0 crash, and bintest 105 OK.
• An MRB_INT32 build with clang and -Wall -Wextra: 1847 total, 1829 OK, 0 KO, 0 crash, and
  no warnings from any mruby-regexp file.
• The struct size was measured on x86_64 only. The 32-bit figure above is read from the layout,
  not measured.

The new test sits next to #7002's, which is the read-side counterpart of this one.

Related to #7002.

Summary by CodeRabbit

• Bug Fixes

  • Fixed handling of very long named regular-expression captures and backreferences.
  • Prevented capture-name length truncation during matching and lookup.
  • Added safe validation for names exceeding the previously supported 16-bit length range.
  • Improved behavior for duplicate and exactly 65,536-byte capture names.

• Tests

  • Expanded coverage for long named captures, named backreferences, and capture lookup.