[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Preventing matches in regular expressions

From: Jan Hudec
Subject: Re: [Gnu-arch-users] Preventing matches in regular expressions
Date: Tue, 10 Aug 2004 14:53:10 +0200
User-agent: Mutt/1.5.6+20040722i

On Tue, Aug 10, 2004 at 08:47:04 -0400, Aaron Bentley wrote:
> Jan Hudec wrote:
> >>Does anyone know a better general solution?
> >
> >
> >A general solution would be to use a negative lookahead assertion. But
> >I don't know whether they are implemented in hackerlab. Hackerlab has
> >something called a "cut" operator. I can't find it's documentation so
> >I am not sure whether it can be used, but I think it can.
> The cut operator is documented here:
> tla-1.2/src/docs-hackerlab/html/introduction-to-regexps.html#The_cut_Operator
> And here:
> tla-1.2/src/docs-hackerlab/html/posix-regexps.html#Posix_Regexp_Functions

Thanks. It is not linked from documentation of the rx module and I was
not looking hard enough.

> The state label  of the final DFA state for most regexps is 1 . If a 
> pattern contains the cut operator  [[:cut <n>:]]   its DFAs will contain 
> a final state with label n  at that point in the regexp. This is useful 
> for detecting which of several possible alternatives actually occured in 
> a match, as in this example:
>      pattern: if[[:cut 1:]]\\|while[[:cut 2:]]
>        pmatch[0].final_tag is 1 after matching "if"
>        pmatch[0].final_tag is 2 after matching "while"
> We were going to use it to optimize inventory operations by combining 
> all the regexes into one.  But it turned out that libhackerlab needed to 
> be fixed, because the cut operator was disabling important regex 
> optimizations.

I see.

                                                 Jan 'Bulb' Hudec 

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]