Hi, > 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).
we are thinking about a "context" based approach for the new API. Instead of pre-defined data structures, there will be getters-setters to set an appropriate list of flags or variables. We don't plan a getter-setter for each flag or variable, e.g. there will be a struct, which contains all allocator related params (malloc, free, realloc pointers, and user params), and it can be get/set by a pcre_[get|set]_allocator(context, pointer_to_this_struct). The details are not finalized. This provides a lot of freedom (internal structures can be reorganized, computed flags can be supported). So there is no need to worry about flags or arguments anymore. Copying, duplicating contexts are also planned, to make it easy to share the same context for several patterns. Regards, Zoltan -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
