------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1134
--- Comment #1 from Richard Smith <exim@???> 2011-08-05 13:10:52 ---
Additional information: the documentation about this is somewhat confusing:
PCRE_INFO_STUDYSIZE
Return the size of the data block pointed to by the study_data field in
a pcre_extra block. That is, it is the value that was passed to
pcre_malloc() when PCRE was getting memory into which to place the data
created by pcre_study(). If pcre_extra is NULL, or there is no study
data, zero is returned. The fourth argument should point to a size_t
variable.
"it is the value that was passed to pcre_malloc() when PCRE was getting memory
into which to place the data created by pcre_study()" does not match the
actual behaviour.
However, it is clarified here:
SAVING A COMPILED PATTERN
...
If the pattern has been studied, it is also possible to save the study
data in a similar way to the compiled pattern itself. When studying
generates additional information, pcre_study() returns a pointer to a
pcre_extra data block. Its format is defined in the section on matching
a pattern in the pcreapi documentation. The study_data field points to
the binary study data, and this is what you must save (not the
pcre_extra block itself). The length of the study data can be obtained
by calling pcre_fullinfo() with an argument of PCRE_INFO_STUDYSIZE.
Remember to check that pcre_study() did return a non-NULL value before
trying to save the study data.
Of course, given that the pcre_exra part of the data block contains a pointer
to the study data part, saving the entire block - along with that pointer -
will not be useful.
This makes it more cumbersome than I imagined to save and restore the data
returned by pcre_study(), but it does now make sense. I think the only thing
that needs correction in PCRE is the comment about the length being that passed
to malloc, which I quoted above.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
