[pcre-dev] [Bug 892] a duplicate named subpattern returns th…

Top Page
Delete this message
Author: JW
Date:  
To: pcre-dev
Subject: [pcre-dev] [Bug 892] a duplicate named subpattern returns the first match/nomatch result for conditional match of that pattern within the expression.
------- 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 <eximbug@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eximbug@???
                   |                            |om





--- Comment #3 from JW <eximbug@???> 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