[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: bug#32194: [PATCH] Use Gnulib regex for lib-src
Date: Sat, 4 Aug 2018 16:34:33 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]