Philip Hazel wrote:
> On Sat, 26 Jan 2008, Sheri wrote:
>
>
>> Here's a user enhancment request. In addition to the software for which
>> I personally compile updated shared libraries, I also use several
>> programs that are statically linked to pcre. These program provide no
>> user commands for accessing the library configuration options, but they
>> do give pattern errors. So what I'm wondering is, could you add a series
>> of (*options) that could be run as patterns to provoke "error" messages
>> that are really informational message about the linked library?
>>
>
> I am unhappy with this idea, for a "gut-feeling-it's-not-right" reason.
> It's all at the wrong level. It really should be the applications that
> are seeking and showing this information to the user. Have you lobbied
> the applications' maintainers?
>
> There are practical objections, too.
>
> - How do you treat a pattern like:
>
> some-stuff(*special-option)morestuff
>
> ? Does it ignore the other stuff? What if there's a genuine error in
> some-stuff (which will be seen first)?
>
> - The pcre_compile() function provides only static error messages. It
> has no means of building dynamic messages. Doing so introduces a
> whole new concept - it would need to get memory in which to build the
> message, and it would have to tell the application that this message
> is dynamic and must be freed - so we've had to change the API in
> order to do this. Not nice. In other words, I see no way of doing
> this without the applications having to be changed anyway, so why not
> change them to show the information?
>
> Philip
>
>
Ok, it seemed like a good idea at the time. I wasn't worried about
options that are under user control like (*special-options) but upon
reflection the application itself could tack on external compile and/or
exec option that would influence matching behavior. For example if the
library is compiled with LF as newline, the application could be always
passing CRLF as a compile time option. So in that event it wouldn't
matter to the end user that the library default is LF. I'm unclear about
the priority sequence of overrides. If the user includes (*ANYCRLF) at
the beginning of a pattern, can the application defeat it with unwanted
external options? Hypothetical example: library default is LF.
Application submits all patterns with a constant external compile and/or
exec option for CRLF. User wants ANYCRLF. Does (*ANYCRLF) trump all?
Thanks,
Sheri
