Closed TomMD closed 3 years ago
OK, I've now come up with a better pattern:
{ .* curl_easy_getinfo ( ^)* x:@ident ^)* ) ^:x* :x = curl_easy_init ( ) .* }
I get how .*
could have been overly greedy. Still not sure if I solved this correctly so I'll leave my ticket open for a little hoping for an education.
That's an interesting example. You are right that the problem seems to be that the . is greedy and tries to read past the closing ) of the argument list -- but it shouldn't because the closing ) that is part of the pattern should be a match (at the same level of nesting) to the opening ( of the argument list. Using ^) before the x:@ident alone also fixes it in my version (slightly updated from the one now on github). I'll put this on my list of things to look into more closely - to figure out why the pattern matching algorithm behaves this way. It shouldn't. Good example.
found and fixed the problem. after some more testing, i'll be uploading the fix later today thanks for the example!
should be fixed now, with the last updates
I think I found a broken pattern but it could easily be my lack of understanding of the pattern language.
Consider:
It seems we should be able to match this patter of
f(x) ; x = g()
or a more generalizedf(x ...) ; ... ; x = g()
using the pattern:But this yields no output. It seems that generalization from
f(x)
tof(x,y)
orf(x,y,z)
really threw us for a loop because this does work:Notice we removed
.*
afterx:@ident
.This is certainly contrary to the english specification on the website ". matches zero or more" since there are zero tokens and . should never make a match that did succeed suddenly fail. Is it a bug? My misunderstanding? Is there another way to approach the pattern?