Re: [pcre-dev] Proposal for a new API for PCRE

On Tue, 27 Aug 2013, Giuseppe D'Angelo wrote:

> The proposal looks great. I do like the OO approach.

Well, it isn't *very* OO. One of the developers wanted a much more OO
approach.

> - Why making PCRE_EXTRA on by default? That will break exiting
> patterns (which albeit "dangerous" do work, then will suddently not
> work any more...)

It's a toss up. As it is, they will suddenly not work if a new escape is
added. It seemed like a good time to make this change. But this is a
minor point. If there is a lot of opposition, I won't press it.

> - Given that JIT-compiling has a cost, in PCRE1 one could compile the
> pattern normally and then, if it was going to be used a lot of times,
> study it with the JIT option. This somehow split the load of normal
> compiling and JIT compiling. What will happen in PCRE2? One will have
> to compile normally, then delete the compiled pattern, and recompile
> it ("from scratch"?) with the JIT option? Is that going to cost more?

This could be solved by providing a function to JIT-compile an already
compiled pattern:

int rc = pcre2_jit_compile(context, pcre2 *compiled_pattern, options);

This could be instead of, or as well as the PCRE_JIT... flags. I think I
prefer instead of, as that is simpler. What do other people think?

> - Is there a way to detect if a pattern is JIT-compiled?

Yes; PCRE_INFO_JIT already does this, and is retained.

Philip

--
Philip Hazel