In <[EMAIL PROTECTED]>, Bart Lateur writes: :On Fri, 29 Sep 2000 13:19:47 +0100, Hugo wrote: : :>I think that involves :>rewriting your /p example something like: :> if (/^$pat$/z) { :> print "found a complete match"; :> } elsif (defined pos) { :> print "found a prefix match"; :> } else { :> print "not a match"; :> } : :Except that this isn't exactly what would happen. Look, "1234E+2" is a :complete string matching the regex, but it could be that it's just a :prefix for "1234E+21". So, /^$pat$/z should fail. No? Yes. :This doesn't seem too intuitive but that's a result from a minimal :interface. Since you have stated, by supplying the /z flag, that the string may not be complete, it seems like the obviously correct result. It is a shame that the interface treats that as a failure, though, so that there is no way thereafter, when you realise that there is no more of the string, to redefine that as a complete successful match with all its attendant behaviour (setting up $1 etc) - in fact, there is no way even to be aware that it could have been a complete successful match. I don't think this is fixable though - I don't see an alternative to redoing the match without /z at that point. Even if we figured out a way to report the result, it does not seem reasonable for the regexp engine to reach the end of string (and therefore be ready to return an immediate failure-with-pos) to go on to try and discover whether it was possible to terminate the match successfully at this point. This is a strength of RFC 93 however, since in that context we don't need to restart the match each time we go off to fetch more data. In that situation if we run out of data after the 1234E2+2 we fail the attempt to widen the \d+, match forward to the $, and are immediately finished. Hugo
