Thank you Philip for your reply.
> I would definitely NOT want to have any more internal global variables.
> PCRE doesn't remember information (except for the malloc/free
> vectors, and with hindsight, I would have done that differently as
> well). The main reason is so that PCRE can be thread-safe.
>
> Some thought would be needed to create some kind of new structure that
> could be passed into the pcre functions - and of course new calls would
> be needed, which would complicate things....
>
> I can't say that I'm very enthusiastic at this stage. Sorry about that.
> I realize that the current state is not ideal.
I'm also not a fan of globals when their storage is done by a
potentially shared component. I agree with and share your concerns
of their implications in multiple threading.
It should be the application caller that supplies the global
storage, with PCRE assigning its own defaults when they are not
supplied by the application.
Attached is an example snippet of C with a ficticious function
pcre_exec_app(). Basically it's a pcre_exec() with the addition
of 1 parameter, an optional pointer to a new typedef struct.
The example illustrates one method of how an application might
communicate its desired settings for 2 of the PCRE run-time
values. The example also includes a pcre_get_app_defaults()
that an application could use to either initialize or discover
default configuration values.
While I would like to extend the application's config to include
the malloc/free vectors, doing that is beyond the scope of the
example because the application's config pointer would need to
be passed along through function calls until the low-level PCRE
malloc/free are encountered. Compatibility with pre-existing
applications may need to be accommodated with #define to newer
functions in order to pass a NULL pointer where application-level
configuration is newly supported.
But regardless, I very much appreciate your time in reviewing
suggestions. Thank you again for all your great work on PCRE.
