Author: ph10 Date: To: Rv CC: pcre-dev Subject: Re: [pcre-dev] New API proposal revision
On Sat, 8 Mar 2014, Rv wrote:
> To be honest, I think that in this way in the case of PCRE2, the export of the
> init function is not necessary (users don't need it, they need of the alloc
> function which does the initialization)
Users *do* need it - if they do not want to use malloc(), but instead
have some private memory management functions.
> My problem is that I am not aware of the problems you could encounter with
> threads (why threads will need to have different private malloc/free
> functions).
I have no experience with threads either, but people who use them need
to be able to pass a thread-specific value to private malloc/free
functions (which you cannot do in the current API). It is true that they
may not need different functions per thread, but there is no reason not
to be as flexible as possible. Also, when people link the PCRE library
from languages other than C or C++, it is not always easy/possible for
them to directly write to global variables (the current API), so a
function-based way of setting private functions is needed. Then where to
store them? The context seems the best place.
> - private_malloc() and private_free() have as second parameter the user data
> and the get function is not useful.
... except as a way for the application to see what is in a context. I
don't know if this will ever be useful, but it is a very small function
and implementing it makes for completeness.
> 1) No defines for the pcre_compile() errrors. I know, there are a lot of
> different errors, but they shall be defined !
I do not think I am clever enough to invent short names for the 85
current compile-time errors. Are names like PCRE2_ERROR_COMPILE_1,
PCRE2_ERROR_COMPILE_2, etc. really useful?
> I thing this is the "negative length means ‘zero-terminated string’" which
> disturbs me.
