------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1209 --- Comment #5 from Philip Hazel <[email protected]> 2012-02-29 18:51:04 --- On Tue, 28 Feb 2012, Rhodri Jenkins wrote: > Yes I did resolve this in a fashion. What I did was add a new function > which I exported from the pcre3.dll. This was void pcre_free_regex (void * > ptr) which call free internally. > > This function just calls free internally on the pointer to the regex > structure I got from pcre_compile. The reason why I need to do this I > believe is that I am calling pcre from C#. There were not way I could find > to call pcre_free successfully because its is a function pointer and I > could not free up the structure pointer because it is allocated on the > unmanaged memory space. The simple exported function pcre_free_regex > worked just fine. It occurs to me that, as you are obviously not changing the default value of pcre_malloc (which just points to malloc), nor the value of pcre_free (which just points to free), you could free the pcre block by calling the system function free() directly, if that is possible from your C# environment. > The other problem I encountered in the windows build files supplied fro > MSVC 2008 do not contain the necessary link and manifest settings to > generate a manifest file. I'm afraid I know nothing about Windows (even less about MSVC). I don't know much about CMake either, but I do know that several Windows users of PCRE use it, and I understand it can generate a number of different build-system's files - I don't know if this includes MSVC on Windows. When you say "windows build files supplied", exactly which files are you referring to? Any windows-specific files in the distribution have been contributed by users, and they never get updated in any other way. > If you are interest in these changes I can supply the amended code with > some instructions. There is basically one extra c file with a three line > function pcre_free_regex.. A function prototype for this function in > pcre.h and migrated solution and project files. If my suggestion above works for you, then I think we need not bother with this. The addition of pcre_free_regex is, however, something to think about anyway, now that we have invented pcre_free_study (which did not exist till recently). There is in any case a long-term issue with the way the current pcre_malloc etc work that impacts on multithreaded programs and on libraries that call PCRE. One of these days there might have to be a complete API re-design, and at that stage there should certainly be something like pcre_free_regex. As far as the solution and project files go, I'm afraid I don't even understand what they are, but they are presumably related to one particular build system. As PCRE already supports two fairly widely used build systems ("configure", well-known in the Unix/Linux world, and "CMake", which works across several platforms including Unix/Linux and Windows) I don't want to take on the maintenance burden of any more. PCRE already takes up enough of my (retired) time! However, if you are just talking about updating files that are already in the distribution, that makes sense. 2008 is a while ago now. Regards, Philip -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
