Re: upstream regex

[Bruno Haible]

[CCing bug-gnulib. This is a reply to
 <http://lists.gnu.org/archive/html/bug-grep/2009-01/msg00011.html>]

Hello Tony,

> > Suggestion: Use the same logic for restrict and restrict_arr as in 
> > gnulib/lib/regex.h.
> 
> What is considered the authoritative source of regex.h? Is it the glibc
> source or the gnulib source? I noticed that the two files are out of
> sync and the glibc is more recent. My understanding, reading the header
> comments of the current grep regex.h file, is that this file should be
> pulled from the authoritative source on regular basis.

The ultimate upstream source of regex (not only regex.h but also regex.c,
regex_internal.[hc], regcomp.c, regexec.c) is glibc. But the glibc sources
are meant to compile only as part of a glibc build, and make assumptions
about the OS (glibc systems) and compiler (it assumes a recent GCC).

The gnulib project maintains a modified version of regex, which is portable
to all systems. Its portability is tested by the fact that coreutils,
findutils, sed, and many other packages use the regex from gnulib.

So, to minimize your maintenance effort while receiving bug fixes for regex,
you have two options:
  - Use the regex module from gnulib. This implies using gnulib-tool
    (see the documentation at http://www.gnu.org/software/gnulib/manual/).
  - Incorporate portability fixes from gnulib on an is-reported basis.
In my bug report, I was following the second option. But using gnulib
via gnulib-tool is more reliable in the long run.

glibc regex and gnulib regex are supposed to be synched (bidirectionally)
regularly. Paul Eggert did this last time in 2006. It's quite some work
to do this synch. Maybe it could be easier, now that we are using 'git'
(using git branches)?

Bruno