jakarta-oro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 16461] - Broken non-greedy regular expressions.
Date Tue, 28 Jan 2003 04:38:03 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16461>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16461

Broken non-greedy regular expressions.

dfs@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From dfs@apache.org  2003-01-28 04:38 -------
I cannot reproduce the alleged problem.  If you think still think it's a bug
in jakarta-oro, please submit sample Java code that reproduces the problem
using the org.apache.oro.text.regex package directly.  This is what I did to
try to reproduce the problem.  I used the following regular expression:

^"([^":]*)/([^":/\\]*)"

and the following input

"file.name" "path/file"

Never mind the substitution.  First we need to test if there is a
match.  For example, using one of the example programs I tried:

java matchResultExample '^"([^":]*)/([^":/\\]*)"' '"file.name" "path/file"'

No match was returned.  It is obvious why that is so.  The regular expression
does not match any part of the input.  The reason it does not match any part
of the input is because of the [^"] rule and the " at the end of file.name.
Notice the results of the following two runs the first with different input
and the second with the ^ removed:

java matchResultExample '^"([^":]*)/([^":/\\]*)"' '"file.name path/file"'

Match: "file.name path/file"
Length: 21
Groups: 3
Begin offset: 0
End offset: 21
Groups: 
1: file.name path
Begin: 1
End: 15
2: file
Begin: 16
End: 20

java matchResultExample '"([^":]*)/([^":/\\]*)"' '"file.name" "path/file"'
Match: "path/file"
Length: 11
Groups: 3
Begin offset: 12
End offset: 23
Groups: 
1: path
Begin: 1
End: 5
2: file
Begin: 6
End: 10

Conclusion: Either the regular expression used in the bug report was
misreported or the problem lies in a misconstructed regular expression.
Again, if you think still think it's a bug in jakarta-oro, please submit
sample Java code that reproduces the problem using the
org.apache.oro.text.regex package directly.  However, please discuss this
on the oro-dev mailing list first so we can verify that it is an issue
before reporting it to bugzilla.  Otherwise we'll just be using bugzilla
bug report comments as a substitute for the support mailing list.

--
To unsubscribe, e-mail:   <mailto:oro-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:oro-dev-help@jakarta.apache.org>


Mime
View raw message