On Wed, 23 Nov 2011, Philip Hazel wrote:
> Oh I see your point. However, in the meantime, I have thought of a way
> to remove the limit without too much work (it will use malloc to
> increase the size of the workspace), so perhaps this doesn't matter.
The size consideration seems like a good candidate to be moved from
pcre_compile.c, becoming a new config.h entry. Perhaps then the need
for malloc could be conditional at compile time depending on whether
or not the size had been raised beyond the default expectation.
It may also be important that the check limit be adjusted with
consideration of LINK_SIZE.
My thoughts, added to your idea of possibly allocating it, are:
In config.h
#define COMPILE_WORK_BASE 2048
In pcre_compile.c
#if (COMPILE_WORK_BASE < 2048)
#undef COMPILE_WORK_BASE
#define COMPILE_WORK_BASE 2048
#endif
#define COMPILE_WORK_SIZE (COMPILE_WORK_BASE * LINK_SISE)
#define WORK_SIZE_CHECK (COMPILE_WORK_SIZE - (50 * LINK_SIZE))
At top of pcre_compile2()
#if (COMPILE_WORK_BASE > 2048)
uschar * cworkspace = (pcre_malloc)(COMPILE_WORK_SIZE);
#else
uschar cworkspace[COMPILE_WORK_SIZE];
#endif
In the places prior to returning from pcre_compile2():
#if (COMPILE_WORK_BASE > 2048)
if (cworkspace != NULL)
(pcre_free)(cworkspace);
#endif
I have a sneaky feeling you've already considered a config.h entry
and adjusting the check. If possible I would prefer not to have an
additional (though temporary) malloc be done within every compile
when configured for the usual most-common PCRE configuration.
Yet I'm only one voice in the forest, one that is very often too
conservative.
> After all, I suspect the occurrence of more than 1000 forward references
> must be quite rare.
That's what I am thinking too. Yet having other significant options
such as LINK_SIZE 3 seems to be useful to a number of applications.
Regards,
Graycode
