Re: [pcre-dev] 7.6-RC2

Top Page
Delete this message
Author: Philip Hazel
Date:  
To: Sheri
CC: pcre-dev
Subject: Re: [pcre-dev] 7.6-RC2
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

--
Philip Hazel