------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1174
--- Comment #4 from Philip Hazel <ph10@???> 2011-11-08 10:11:38 ---
On Tue, 8 Nov 2011, Gertjan Halkes wrote:
> If by compile-time you mean the call to pcre_compile (or
> pcre_compile2) and not the compile of the pcre library itself, then
> yes, this would meet my needs.
Yes, I do mean that. Good.
> Basically, the only time this solution would be insufficient, is when
> a library wants to use some special purpose allocation code, which
> will probably be rare.
Indeed, that is what I was thinking as well, especially as nobody as
brought up this issue before. This is certainly the easiest solution,
and it does not rule out doing something much more drastic later if that
turns out to be necessary.
> As a side note: the pcreapi man-page currently says to free the memory
> allocated by pcre_compile using pcre_free. This would have to change as well
> probably, regardless of the eventual solution. For the less invasive solution
> either by updating the man-page to say free must be used directly when using
> PCRE_USE_MALLOC, or supplying a separate function to free the result of
> pcre_compile and friends.
Thank you for pointing this out (I might have overlooked it). As we have
just introduced pcre_free_study() for study data, and we already had
pcre_free_substring() and pcre_free_substring_list(), it might make
sense to have pcre_free_compile() as well, to complete the set.
Regards,
Philip
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
