Autor: Philip Hazel Datum: To: Tom Bishop, Wenlin Institute CC: PCRE Development Mailing List Betreff: Re: [pcre-dev] [Bug 1295] add 32-bit library
On Sat, 27 Oct 2012, Tom Bishop, Wenlin Institute wrote:
> I don't know if anyone has had a chance yet to study the change I
> proposed in an earlier message.
I have to confess that I have (almost) ignored this, because I was
leaving all the 32-bit stuff to other people, and I have no experience
or knowledge about the use of UTF-32.
> It's fine to have explicit ways to override these conformance
> requirements (I propose a macro PCRE_MASK_UTF32_BEYOND_1FFFFF), but
> PCRE_NO_UTF32_CHECK in itself should only turn off the error
> reporting, not turn off the conformance.
I think I would agree with you, not only for the conformance, but
because this is using one switch to adjust two things, and that seems
wrong to me.
> It's good that the masking with 0x1fffff now only occurs if
> PCRE_NO_UTF32_CHECK is specified. The Unicode conformance can be
> improved, and the code made slightly smaller, faster, and more
> flexible, with a simple change to pcre_internal.h. By default,
> PCRE_NO_UTF32_CHECK should disable checking without enabling masking.
> Masking can be enabled by a compile-time option.
I did skim the previous correspondence on this, and it seemed to me that
there were two groups of people who felt strongly for both features:
mask and no mask. In these situations, providing an option is usually
the best way to satisfy both parties.
However, the problem with using a compile-time option is that it does
not allow for different uses of the same library, and this may be
relevant for packaged systems. A number of Linux distributions (for
example) bundle PCRE, and the packagers would have to choose mask or no
mask without any knowledge of what the end users wanted.
So, if there really is a need for this masking (and I guess there is,
otherwise the issue would not have been raised), I suppose we have to
provide another *runtime* option rather than a compile-time option.
There are only two runtime option bits left but maybe this is important
enough to use one of them. (There is a little bit of wiggle room in that
some options are used only for compile or only for exec, and these could
be overlayed for new exec or compile options, but that would make it
easier to make mistakes.)
