--- In [email protected], "entropyreduction" <alancampbelllists+ya...@...> wrote: > > --- In [email protected], "Sheri" <sherip99@> wrote: > > > > --- In [email protected], "entropyreduction" > > <alancampbelllists+yahoo@> wrote: > > > > > > While pouring over pcre.h and docs I find > > > PCRE_NO_START_OPTIMIZE > > > > > > Don't think I've covered that? Should I have? > > > Until now that would only be useful during callouts (which are disabled in > > the plugin). But when marks are implemented that could change. So I would > > say yes, implement PCRE_NO_START_OPTIMIZE as "slow" with no short version > > (but I don't expect it to get much usage). > > Ok. Compile? Exec? Both?
Per the docs it seems to be an exec option > > > when executing pcre_dfa_exec I see the options > PCRE_DFA_SHORTEST Return only the shortest match > PCRE_DFA_RESTART Restart after a partial match > > Have I done them? Haven;t looked yet, but don;t ring a bell. yes, see the plugin options page of the regex.chm help file > > pcre_dfa_exec dos say for extra data options: > > "the match_limit and match_limit_recursion fields are not used, For this > matching function, the match_limit and match_limit_recursion fields are not > used" > > Not sure if I made that sanity check. Will look > > and in same docs the mark field isn't shown in the struct or mentioned, so I > imagine it too shouldn;t ever be allowed with dfa option? agree, because mark is only mentioned in connection with pcre_exec, not pcre_dfa_exec > > Does mark make sense with pcrematchcount? Probably not. I would think that the only places it makes no absolutely sense is where pcre_exec will not get used (e.g., pcreCompile), so I guess I would not exclude it from pcrematchcount. User should be cautioned not to apply the option there (or anywhere) unless he/she plans to retrieve the mark if pcre happens to set one (which it would only do if the user's pattern asks for one and the conditions encountered support it). But, if it is a mess to implement, it is ok with me if you want to exclude it from everything except pcreMatch and pcreReplaceCallback. Main thing is, do not ever want the overhead unless the option has been set. > > Is PCRE_UCP both exec and compile option, or just one, if so which? compile time only afaict > > docs say "PCRE must be built with UTF-8 support in order to use PCRE_UTF8 and > PCRE_NO_UTF8_CHECK, and with UCP support if PCRE_UCP is used." > > Did you built with UCP and UTF-8 support? > Yes, always have. The options I always use are (courtesy of pcretest -C): UTF-8 support Unicode properties support Newline sequence is ANYCRLF \R matches CR, LF, or CRLF only Internal link size = 2 POSIX malloc threshold = 10 Default match limit = 10000000 Default recursion depth limit = 10000000 Match recursion uses heap Regards, Sheri
