On Sat, 12 Nov 2011, Graycode wrote: > That makes sense, thanks. Since each program gets its own copy of > library data then I would not see a problem with the library having > storage variables. The values of those variables would be unique to > each program so one would not blow out the data seen by another one.
Unique to each program, yes, but shared between each thread of control, and that is where there is a potential issue (as well as the library issue). > I'd blame the other library for not using a static build of its PCRE > functionality. The problem with that is that it freezes the version of PCRE it uses into the static build. If a major bugfix is applied to PCRE, the library's static version won't get it until it is rebuilt. With shared libraries you get the latest version automatically. (And, for the record, there are mechanisms for handling changes of API, but this isn't the place to go into them.) > It leaves me scratching my head over any differences established in > PCRE's config.h in situations like that. Maybe only one of them > wanted to have SUPPORT_UCP, SUPPORT_UTF8 or SUPPORT_JIT. And perhaps > one of them intended to have MATCH_LIMIT 20000. I don't see how > issues could be resolved by relying upon a program's linkage if there > could be different conflicting PCRE compilations at play. General-purpose versions of PCRE, such as those installed as standard in a number of OS, usually include all available facilities. Cutting out what you don't need is normally done only in controlled environments such as "closed box" applications where the set of programs that will use the library is known, and you want to minimize memory use. > On the other hand if there is one single shared PCRE libary instance > built which is used by everything, including being used by other > generic linked-in libraries, then that PCRE instance would need to > contain and deploy a maximum of what everything MIGHT want to use. > I wouldn't want to do that, Why not, if this is the ONE copy for the whole of an operating system? All you ever need to maintain/update is this one instance. > Am I in the minority in defining options and building PCRE according > to the tasks at hand vs. a single one-for-everything? I feel so ... > old-school. I think you are, when considering a general-purpose operating system, but you are not when considering a tightly-controlled special-purpose environment. PCRE is supposedly flexible enough to be useful in both cases. > As you tried to tell me, supporting those environments boils down to > PCRE not being allowed to have any global read/write variables. Absolutely. > I might favor having those variables and not supporting the kind of > deployment that induces the problems. ... but we software developers like to have our code used as widely as possible! I have never used Windows, let alone programmed for it (this is mostly accident rather than deliberate), but I am happy to work with Windows people to enable PCRE to be used there. Similarly, I don't use 16-bit character codes or UTF-16, but I'm participating in discussions as to how PCRE might support them. > Your solution of a pointer to storage administered by the caller seems > like a good one. That is the "traditional" way of handling such issues. > I've been corrected. Windows manages stack size using 64K allocation > increments. Even though the code specifies 32K and throttles PCRE as > if there was only 32K, the threads are acually getting 64K stack. Still impressive. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
