Author: Philip Hazel Date: To: Roman Rybalko CC: pcre-dev Subject: Re: [pcre-dev] [PATCH] Re: External memory allocator interface
On Wed, 9 Jul 2008, Roman Rybalko wrote:
> > If it is easy, please send me patches for what you have already done so
> > that I can look at them and decide if I like them. :-) I want to check
> > the impact on exising uses of PCRE that do not need to use this extra
> > feature.
> >
> Here it is.
> Without any build-system integration.
I have a few comments.
I'm slightly worried about the need to impose another level of function
call on the "normal" use of PCRE, though I suppose it is only a small
performance penalty, and I cannot see any way of getting round it.
I think your functions pcre_mm_malloc() and pcre_mm_free() should be
macros that expand inline, for better performance. The coding convention
in PCRE is that macros have upper case names, incidentally. I know
"asserts" are useful for debugging, but I think they should not probably
be in the production version.
I don't think it is worth having a separate pcre_mm.h; everything in
there could go into pcre.h.
You haven't done anything about pcre_stack_malloc. Maybe that could be
ignored, though it does leave things incomplete. I suppose the only
logical approach is to add it to the mm structure.
Some of the functions for which you have listed mm versions don't use
malloc or free. For example, pcre_fullinfo(), pcre_dfa_exec(), and the
pcre_copy_xxx() functions.
