[pcre-dev] [Bug 2283] RE::error() is nonempty even if compil…

Top Page
Delete this message
Author: admin
Date:  
To: pcre-dev
Subject: [pcre-dev] [Bug 2283] RE::error() is nonempty even if compilation succeeds
https://bugs.exim.org/show_bug.cgi?id=2283

--- Comment #11 from Philip Hazel <ph10@???> ---
(In reply to ksuarz from comment #10)
> Created attachment 1091 [details]
> More idiomatic C++ fix for (*UCP) and friends
>
> Alright, I've taken a whack at it. I am not familiar with svn-speak, but in
> Git parlance I've made a patch based off the tip of master (trunk?). I tried
> my best to use more idiomatic C++ string features while staying as true as
> possible to your coding style. Sorry if I'm breaking any of the project
> conventions.


As this is not my code (and I'm no C++ programmer), that's not an issue! But
thanks for worrying.

> I have tested the change; it passes all of the tests in my project's unit
> tests as well as the PCRE unit tests (though for some reason I still doubt
> that my ./configure is properly enabling UCP).
>
> Let me know if there's more testing to add, or if I should run it through a
> linter, etc.


It may be that I don't understand the C++, but on my reading of your code I am
worried that it is not matching the special strings only at the start of
pattern_. Is there a way to confine pattern_.find() to that behaviour? For
example, it is correctly handling (*UTF8)XXXX, but if the pattern is actually
YYY(*UTF8)XXX it should leave it unmodified. [Such a pattern would later give a
compiling error.]

In other words, should "if (search == string::npos) continue;" really be
"if (search == string::npos || search != offset) continue;" ?

Or am I mis-reading your code? I guess I should create a test...

--
You are receiving this mail because:
You are on the CC list for the bug.