bug#32194: [PATCH] Use Gnulib regex for lib-src

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 17 Jul 2018 16:47:29 -0700
> Cc: Paul Eggert <eggert@cs.ucla.edu>

> Emacs regular expressions forked from everyone else long ago.
> This makes it official and should allow simplification later.
> etags.c now uses the glibc regex API, falling back on a
> Gnulib-supplied substitute lib/regex.c if necessary.
> Emacs proper now uses its own regular expression module.

Thanks.

I have a couple of comments on this.

1. The test for regex being available in the system library seems to
   assume the regex routines are in libc, is that right?  (I didn't
   try to apply the patch, just read it, so apologies if I missed
   something.)  If so, would it be possible to let the configure
   script also check -lregex for those functions?  This could be
   important on non-glibc systems.

2. Do we really need to rename src/regex.c?  We could have 2 regex.c in
   separate directories, couldn't we?  If possible, I'd prefer not to
   rename files, as that makes VCS forensics more complicated.

3. Is it really necessary to pull mbrtowc, locale_charset,
   nl_langinfo, and their dependencies?  That brings a lot of code,
   where src/regex.c needed none, although it did call btowc.  We
   currently simply expect btowc to "just work"; why can't we do the
   same with mbrtowc?  The etags needs for non-ASCII stuff are a very
   small subset of what we need in Emacs -- in a nutshell, at most it
   needs to handle only the current locale.  The code we pull from
   Gnulib supports much more, and the related test programs are much
   more demanding, so platforms will fail the tests where they don't
   have to.  For example, AFAICT on MS-Windows many tests will fail
   because UTF-8 is not supported by the C runtime.

   So I'm asking whether we can take a step back and consider
   importing just regex.[ch] without all the supporting stuff, and
   assume that the libc functions it calls will work well enough for
   etags.

P.S. Is it true that this version will no longer support a build with
WIDE_CHAR_SUPPORT undefined, i.e. those which have only the C locale?