On Sat, 8 Jun 2013, Thorsten Schöning wrote: > > An application may use either OPCRE or NPCRE, but not both. > > Why should one need that restriction if NPCRE already is a dependency > for OPCRE and therefore must be used in an application? Why shouldn't > one be able to use both APIs, especially with different function > names, if one is forced to build and link both libraries?
My thought was that the application only has a dependency on OPCRE. OPCRE would contain NPCRE but not expose its definitions or functions to the application. I think one of the drivers for a new API is that the current (int) option bits are pretty much all used up. I don't know how the new API might address that. I'm saying that OPCRE would still define its options as (int) while the equivalent set of options in NPCRE might not fit in a single (int). I don't feel comfortable with option #2 whereby both the old and new could coexist and be utilized together. > > The documentation should state that OPCRE is transitional. At some > > future date the OPCRE project may be abandoned, or perhaps it will > > just remain static for very long intervals. > > I don't see the benefit of an OPCRE for maintainers or users, users > who don't want or are able to upgrade at least should be in a position > to use the latest versions of "old PCRE" without changing any of their > infrastructure and this would mean that old PCRE simply stays > untouched as it is and the new API is simply that, a new library which > one can use or not. There it seems you're suggesting option #1 and that's fine with me. Let the new API be a solid basis for the future without being limited by concerns for compatibility with the old API. That's probably the best and easiest approach. My suggestion of OPCRE was for a wrapper that could allow many current (old) applications to recompile or just re-link and thereby be able to gain up-to-date NPCRE benefits such as any new pattern features, speed improvements, security fixes, etc. It would not be a solution for all applications because it would probably not attempt to encompass all of the features & options available in PCRE 8.33. In any case, my preference is to avoid the new API trying to contain both the old and the new interfaces. Perhaps the determination for having any level of old compatibility depends upon the specifics of what the new interface will be. Regards, Graycode -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
