------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1357
--- Comment #6 from Carsten Klein <cklein05@???> 2013-07-01 14:12:19 ---
I'm not sure whether it is worth to only ensure that PCRE_CALL_CONVENTION is in
place, without adding real functions for memory management. So, if you decide
not to implement the VB6COMPAT option, you need not care for the
PCRE_CALL_CONVENTION macro as well.
The problem is that those programming languages, that actually need a calling
convention different than __cdecl (which are Visual Basic 6, VBA and all .NET
languages) are not able to call a function through an exported function pointer
(to be correct, the .NET platform supports calling __cdecl functions but not
through a function pointer).
So, for these languages it is not possible to call pcre[|16|32]_free, which is
truly a showstopper, since memory leaks are inevitable.
However, since I'm able to maintain my own codebase for the old/current 8.xx
API, I can, of course, live with that (given that the new version/API will
come).
Including the PCRE2_CALL_CONVENTION macro into a macro for defining/declaring
functions is probably a good idea.
Carsten
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
