From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#32194: [PATCH] Use Gnulib regex for lib-src Date: Sat, 04 Aug 2018 18:41:38 +0300 Message-ID: <83a7q2t9zh.fsf@gnu.org> References: <20180717234729.15507-1-eggert@cs.ucla.edu> <83va9c33kk.fsf@gnu.org> <15823bbe-8298-0d69-c7a6-edf2001e4513@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1533397209 14703 195.159.176.226 (4 Aug 2018 15:40:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Aug 2018 15:40:09 +0000 (UTC) Cc: 32194@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 04 17:40:05 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1flyey-0003iu-MM for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Aug 2018 17:40:04 +0200 Original-Received: from localhost ([::1]:55381 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1flyh3-0002JE-Ik for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Aug 2018 11:42:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1flygv-0002J5-2F for bug-gnu-emacs@gnu.org; Sat, 04 Aug 2018 11:42:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1flygt-00011u-Up for bug-gnu-emacs@gnu.org; Sat, 04 Aug 2018 11:42:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36089) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1flygt-00011p-PV for bug-gnu-emacs@gnu.org; Sat, 04 Aug 2018 11:42:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1flygt-0004fY-Gm for bug-gnu-emacs@gnu.org; Sat, 04 Aug 2018 11:42:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Aug 2018 15:42:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32194 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 32194-submit@debbugs.gnu.org id=B32194.153339731717936 (code B ref 32194); Sat, 04 Aug 2018 15:42:03 +0000 Original-Received: (at 32194) by debbugs.gnu.org; 4 Aug 2018 15:41:57 +0000 Original-Received: from localhost ([127.0.0.1]:41107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1flygn-0004fE-3i for submit@debbugs.gnu.org; Sat, 04 Aug 2018 11:41:57 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1flygl-0004f0-JO for 32194@debbugs.gnu.org; Sat, 04 Aug 2018 11:41:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1flygd-0000ql-3o for 32194@debbugs.gnu.org; Sat, 04 Aug 2018 11:41:50 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46175) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1flygc-0000qh-Vw; Sat, 04 Aug 2018 11:41:47 -0400 Original-Received: from [176.228.60.248] (port=1594 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1flygc-0007HL-CB; Sat, 04 Aug 2018 11:41:46 -0400 In-reply-to: <15823bbe-8298-0d69-c7a6-edf2001e4513@cs.ucla.edu> (message from Paul Eggert on Tue, 31 Jul 2018 11:21:38 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:149262 Archived-At: > From: Paul Eggert > Cc: 32194@debbugs.gnu.org > Date: Tue, 31 Jul 2018 11:21:38 -0700 > > Eli Zaretskii wrote: > > > would it be possible to let the configure > > script also check -lregex for those functions? This could be > > important on non-glibc systems. > > It would no doubt be possible. However, we haven't found a need in other > applications that use Gnulib. Gnulib code tends to be more up-to-date > than system-supplied libraries, and in practice it's OK if the system > puts the regex code in a place where 'configure' won't find it, as Emacs > will just fall back on the better Gnulib version in that case. 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. > > 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. > > Renaming src/regex.h works around problems with having two include files > src/regex.h and lib/regex.h that fight each other. I tried not renaming > src/regex.h at first, and then ran into problems and gave up; although I > surely could get it to work eventually, I figured that we'd continue to > have ongoing problems and so it would be better to bite the bullet. Too bad, but I guess we have no choice. 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. > > 3. Is it really necessary to pull mbrtowc, locale_charset, > > nl_langinfo, and their dependencies? > > I didn't know, so in my first cut I did the easiest thing and pulled > them all in. It's pretty easy to omit them; we can always add some back > if we find they're needed after all. Revised patch attached; it is the > first patch in the attached series. (The later patches are some of the > simplifications mentioned above.) OK, thanks. > > 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. So platforms which don't have WIDE_CHAR_SUPPORT will now be required to provide it, or will fail to compile/run. Am I wrong? > OK, revised patchset attached. This keeps the debugging code in question. I took > the liberty of renaming DEBUG (which clashes with other DEBUGs) to > EMACS_REGEX_DEBUG. Fine with me. > (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? Thanks. P.S. I think 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.