------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1490
Markus Mottl <markus.mottl@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Markus Mottl <markus.mottl@???> 2014-06-06 19:36:14 ---
I have decided to fix the problem in my OCaml bindings so no change is required
anymore.
(In reply to comment #1)
> I don't understand your last sentence because pcre_exec() already has a
> startoffset argument that does exactly this. Its use is demonstrated in
> the pcredemo.c file that is part of the PCRE distribution.
True, but if the offset is non-zero, the matching engine may still "look
behind" the startoffset. This is actually documented in the man page, but I
didn't know about this behavior until a user filed a bug report for his
peculiar pattern.
> I'm confused. If you want "this position" to be the true start of the
> string, then surely you can just pass it as the subject string to
> pcre_exec()? What am I missing here?
I initially wanted to avoid this, because it required some non-trivial changes
to my bindings and seemed like an easy flag to add to PCRE. OCaml doesn't
allow you to do pointer arithmetic on strings for safety reasons so I had to
pass through an extra offset each time my code needs to call pcre_exec and then
rewrite the results in "ovector" after matching and before callouts.
I eventually concluded that some people might actually need the current PCRE
semantics for unusual cases so just having an extra flag wouldn't have resolved
my issue anyway. Hence I chose to go for the more involved fix in my library.
Thanks for your great work on PCRE!
Best regards,
Markus
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
