Build success for 3.4.3-rc0 on Linux, Kubuntu 10.04

[John W. Eaton]

On 29-Sep-2011, Rik wrote:

| Another good build with all tests passing.
| 
| One interesting warning during the compilation:
| 
| regex-match.cc:123: warning: unused parameter 's'
| 
| The function is shown below.
| 
| bool
| regex_match::match (const std::string& s)
| {
| #if HAVE_REGEX
|   int npat = pat.length ();
| 
|   const char *str = s.c_str ();
| 
|   for (int i = 0; i < npat; i++)
|     if (regexec (compiled + i, str, 0, 0, 0) == 0)
|       return true;
| #endif
| 
|   return false;
| }
| 
| Is this related only to my system or is HAVE_REGEX redundant now that we
| require PCRE to build?  I'm thinking it may be left over from when there
| was a distinction between generic regular expressions and Perl regular
| expressions.

I also noticed this problem recently and thought I posted a message
about it but now I can't find it.

I thought Octave's code for handling of regular expressions code was
organized so that if PCRE was available, we would use that, otherwise
we would fall back to using the POSIX regex functions.  I didn't
notice that the regex_match class was not written to use PCRE or POSIX
regex functions, but instead POSIX regex functions or nothing...

So when we switched to requiring PCRE, we disabled support for POSIX
regex functions, but we are still using them in some places.
Fortunately, these features are probably not commonly used.  For
example, the only thing I see is the clear function when called with
the -regexp option.  So currently, that feature does not work as it
should.

In the short term, we could restore the test for POSIX regex functions
to configure.ac (but without disabling PCRE if they are found) and
make this work again, or we could just let it slide since this is
likely a very seldom-used option to the clear function and we have
seen no reports about it.  Probably very few people even know about it
and fewer people use it.

Longer term (like for the 3.6 releaes), it would be good to move the
interface for PCRE from DLD-FUNCTIONS/regexp.cc to liboctave's
regex_match class (or something similar) so that we can easily use
regular expression functions anywhere in the Octave internals, and
have them consistently handled by PCRE instead of sometimes POSIX,
sometimes PCRE...

jwe