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.

struct _GRealRegex
{
  gchar *pattern;	/* the regular expression */
  gint match;           /* tri-value flag, 1 if a match was made, 0 if not, -1 initial */
  gint matches;		/* number of matching sub patterns */
...
};

Do you really need the boolean "match" flag?  The number of matches
returned by pcre_exec() is < 0 if no match was made, and 0 if it ran out
of memory for storing the captured strings' offsets.  The latter case
won't ever happen though because g_regex_new() always allocates the
maximum necessary space for the output vector.

Also, I see you're using pcre_info() which is deprecated and has been
replaced by pcre_fullinfo().  This probably doesn't matter much since a
modified pcre will be shipped with GLib -- but I'd suggest to use
_pcre_fullinfo() and remove _pcre_info() completely.

Another important issue: I'm using pcre in regexxer (a module of the
same name can be found on cvs.gnome.org), and I had to write a function
that searches for "\C" the pattern string and bails out if found.  The
"\C" escape sequence always matches a single byte even if it's part of a
multi-byte character, thus causing loads of trouble.  It might be a good
idea to remove "\C" from the pcre shipped with GLib.  Alternatively
another flag could be added to the compile options to make recognition
of "\C" optional.

All in all it'd rock if this patch could go into CVS soon, so I may test
it extensively in regexxer and report back how it went.  Thanks Matthias
for your work -- the new API is going to spare regexxer one dependency!

Cheers,
--Daniel