GNU bug report logs - #32194
[PATCH] Use Gnulib regex for lib-src

Previous Next

Full log

Message #59 received at 32194 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32194 <at> debbugs.gnu.org
Subject: Re: bug#32194: [PATCH] Use Gnulib regex for lib-src
Date: Sat, 4 Aug 2018 16:34:33 -0700

Eli Zaretskii wrote:

> The idea is that the system-supplied regex library is also GNU regex,
> but one tuned better to the specific platform.  The configure script
> could check whether that library is up to speed, before using it.
> 
> Obviously, not a terribly important issue, but I've seen projects that
> do this.

I doubt whether any platform has a system-supplied regex library compatible with 
the glibc API and performing significantly better. The glibc code is hairy and 
was written by an expert and its behavior would be hard to replicate. In the 
unlikely event that there is such a platform and it requires unusual flags, that 
platform's builder can simply configure with the appropriate CFLAGS, LDLIBS, 
etc. We needn't worry about this unlikely event.

> I'd only ask that the
> renaming be done as a separate commit before the rest of the changes
> in those two files, so that all the changes in src/regex.[ch] will be
> after the rename, as that will make future forensics easier.

OK, will do.

>>> 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?
>>
>> I don't see any issues with such a build. What sort of problem do you
>> have in mind?
> 
> AFAIU, you suggest removing the !WIDE_CHAR_SUPPORT code, but we
> previously supported platforms that don't have all the prerequisites
> for using that code.

If I understand you correctly, I doubt whether such platforms survive now. If 
they do we can add Gnulib-based substitutes for the missing prerequisites. I 
already did that in Bug#32194#5; you suggested in Bug#32194#8 point (3) that we 
not bother with it, though, and this seemed like good idea so that's what in the 
current proposal. If the idea doesn't work it will be easy to go back to the 
approach in Bug#32194#5 (as I recall it's a simple change to admin/merge-gnulib 
followed by turning the crank).

>> (malloc, realloc, free): Do not redefine.  Adjust all callers
>> to use xmalloc, xrealloc, xfree instead.
> 
> Is this wise?  xmalloc etc. are tuned to allocate Lisp data and
> aligned objects, something that isn't necessarily needed in regex
> library.  Why not use the normal memory allocation routines?

src/regex.c is already using Lisp allocation when compiled as part of Emacs, so 
this is just code simplification, not a real change. The Emacs regex code needs 
to use xmalloc to do the right thing with memory exhaustion and to do memory 
profiling.

> we should compare the performance of etags before and
> after the switch, just to be sure we aren't going to suffer a
> performance penalty.

I expect there to be a performance penalty but it's no big deal. On my old 
Fedora 28 x86-64 platform with 'make TAGS CFLAGS='-O2 -march=native"' in the 
Emacs src directory, user+system time grows from 0.55 to 0.59 seconds, about a 
10% slowdown. It grows about 10% more, to 0.64 seconds, if I use the 
system-installed regex library instead of the Gnulib-supplied one. I don't view 
an extra tenth of a second as a glitch big enough to be worth investigating.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.