------- 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 <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
