------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=892 JW <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] | |om --- Comment #3 from JW <[email protected]> 2009-10-01 00:17:05 --- (In reply to comment #2) > This is an inevitable consequence of the way duplicate names are fudged into > PCRE, and is a related issue to #760. The problem is that the compiled code > works entirely in terms of capturing parenthesis numbers, not names. When > compiling the test for "is pattern <name> set?" it just picks the first number > that is associated with <name>. In your pattern, the compiled code contains a > test for subpattern number 1. > > A deeper question is this: If there are two or more subpatterns with the same > name, what does "is pattern <name> set?" actually mean? Does it mean "any" or > "all" of the named subpatterns? I suppose "any" is the more useful. > > This is unlikely to be changed soon, unless I can think of some cunning way of > handling it. I am in the last stages of preparing a new release; I can't say > whether I will have inspiration in time or not... > ironically, the "(?|" feature to set up multiple sub-patterns with the same number at issue in #760 works around the duplicate name conditional as the index will correctly match if the duplicate names are in different sections of the multiple. where duplicate names are allowed, tracking/associating with each pattern name the 'last match' (or 'first match') capturing parenthesis number and looking to *that* association to determine the pattern number (for both conditional and named backreferences) would solve the issue. but then again, what do I know. -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at http://lists.exim.org/mailman/listinfo/pcre-dev
