| Ticket UUID: | 41bc9a82988d930fc00145bcd02bb3ce4e169a2c | ||
| Title: | regsub -command panics with more than 9 capturing groups | ||
| Type: | Bug | Created on: | 2026-10-11 06:54:45 |
| Submitter: | serhiy.storchaka | Assigned to: | |
| Subsystem: | 43. Regexp | Severity: | Severe |
| Priority: | 5 Medium | Last modified: | 2026-10-11 07:06:58 |
| Status: | Open | Closed by: | |
| Resolution: | None | Closed on: | |
| Version: | 9.0.5, 9.1.0 | ||
| Description: | ||||
|
regsub -command with more than 9 capturing groups can panic:
set re {(a)(b)(c)(d)(e)(f)(g)(h)(i)(j)(k)(l)}
regsub -command $re abcdefghijkl {apply {args {list [llength $args] $args}}}
In 9.0.5 this panics with "unable to alloc 643662021519030588 bytes". In 9.1.1 it happens not to crash, but the last three arguments are empty instead of j k l. Valgrind reports uninitialised reads in Tcl_RegsubObjCmd() in both.
Tcl_RegsubObjCmd() always asks the regexp engine for 10 submatches, but with -command it passes all info.nsubs + 1 of them to the command, reading entries of the match array that were never set, and uses them as string positions and lengths. Asking for all submatches when -command is used fixes it; regsub.n also says that each substring matching a capturing sub-RE is appended. | ||||
| User Comments: | ||||
serhiy.storchaka added on 2026-10-11 07:06:58:
Proposed fix in branch regsub-command-all-submatches: with -command, ask the regexp engine for all submatches. Tests regexp-32.1 and 32.2. | ||||