Fleggy, I executed the three Perl regular expressions posted by you on the three sample blocks posted byÂ
Gabarito (ANSI, DOS) and the attached XUL file (UTF-8, UNIX) using UE v25.00.0.68, v24.20.0.62 and v22.20.0.49 (32-bit versions).
F: (?s)(?:(?<!loadURI\(").)++(http(?:(?!").)++)|.*
R: \1\r\n
This first posted expression makes a quite good job as long as a URL starts with
http. On first occurrence of a URL after
loadURI(" not starting with
http the Perl regular expression engine makes the right job: it back tracks to beginning of already matched string and applies second OR argument
.* to match greedy everything up to end of file. Therefore the result of running a replace all with that expression is wrong if there is any url not starting with
http in file.
Next I should run tests with:
F: (?s)(?:(?<!loadURI).)++\("(http(?:(?!"\)).)++)
R: \1\r\n
This expression is really a problem for the Boost Perl regular expression library on first occurrence of a URL not starting with
http. It looks like the library runs into loop after finding
loadURI(" without
http on finding out where in characters stream to restart the search causing more and more usage of stack memory until limit reached. This expression works on the small sample blocks producing the result according to expression, but on XUL file the block after first URL not starting with
http is too large and the result is the error message:
The complexity of matching the expression has exceeded available resources.
The third expression posted is:
F: (?s)(?:(?<!loadURI\(").)++((?:(?!").)++)|.*
R: \1\r\n
And this one without limitation of URL must start with
http works fine for the sample blocks as well as for the entire XUL file with all three versions of UltraEdit with the minor exception of producing a blank line at end of file because of replacing file content after last URL by a carriage return + line-feed instead of nothing to just remove that block.
There was no crash on running the tests with used versions of 32-bit UltraEdit. The
Undo command worked also always fine without verifying if it really restored original file content always 100% correct. But I would not be surprised if the second search expression causes a crash depending on file content, character encoding and line ending type as it cause an undefined behavior on execution.
