Re: glib regular expession api

[Daniel Elstner <daniel elstner gmx net>]

Am Do, den 03.06.2004 um 21:00 Uhr -0400 schrieb Matthias Clasen:
> Last night I've dusted off an old patch which adds regular expression
> support based on PCRE to glib. Here is the api which I currently have.
> Does this look reasonable ? The full patch is attached to bug 50075.

Another problem in g_regex_match_next():

  gregex->matches = _pcre_exec (gregex->regex, gregex->study_data,
				string + gregex->pos, remainder_len,
				0, gregex->match_opts | match_options,
				gregex->offsets, gregex->offset_ct);

  /* if the regex matched, adjust the offsets array to take into account
   * the fact that the string they're out of is shorter than the string
   * that the caller passed us, by regex->pos to be exact.
   * Then, update regex->pos to take into account the new starting point.
   */

Why don't you use the offset parameter of _pcre_exec() to accomplish
this?  Note that incrementing the string pointer is not the same as
passing a start offset > 0 to pcre_exec() due to the possibility of back
references.

I reckon g_regex_match_next() is intended to implement the "/g" flag as
in Perl?  If so, you have to set the PCRE_NOTEMPTY flag when matching
again with the same offset, and if that fails advance the offset by one
character and continue matching without PCRE_NOTEMPTY.  This is
explained in detail in the pcreapi manpage.  You might also want to look
at my FileBuffer::find_matches() method you find here:

    http://cvs.gnome.org/viewcvs/regexxer/src/filebuffer.cc?view=markup

The "multiple" flag means "/g" is being used.  It's C++ code, sorry.

Cheers,
--Daniel