The ARE options parsing code looks for ARE options flags at the beginning of the expression. Thee ARE option flag definitions look something like the following:
(?x)
The code currently assumes that any expression starting with "(?" starts with one of these ARE option strings. However, this causes expressions which start with non-capturing groups to be improperly parsed. For example:
(?:dont capture x)?but capture y
is parsed as an ARE option string (which happens to contain the "x" flag!), not as 0 or 1 occurances of the string "dont capture x". Since the parsing code assumes the expression is valid, the expression which remains after the improper ARE options parsing would be:
?but capture y
which then tries to reference the portion of the expression prior to the "?". The end result of this is a segfault.
This bug was observed on Solaris 10 using the expect-20081003.tar.gz tarball.
I've attached a patch to correct this behavior by verifying that the initial "(? ... )" string contains only characters understood to be ARE options flag characters. If any non-flag characters are found the string is left to the main parsing loop to deal with. Otherwise, it is treated as a list of ARE options and consumed. Please integrate this (or similar) fix into CVS at your earliest convenience! Thanks in advance.
Patch correcting improper parsing
Same patch as unified diff
Fixed in CVS head, version bumped to 5.44.1.12