From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#32194: [PATCH] Use Gnulib regex for lib-src Date: Sat, 4 Aug 2018 16:34:33 -0700 Organization: UCLA Computer Science Department Message-ID: <2d8e4d2b-c6b1-4e39-dfb0-d10b75d9caf8@cs.ucla.edu> References: <20180717234729.15507-1-eggert@cs.ucla.edu> <83va9c33kk.fsf@gnu.org> <15823bbe-8298-0d69-c7a6-edf2001e4513@cs.ucla.edu> <83a7q2t9zh.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1533425651 11748 195.159.176.226 (4 Aug 2018 23:34:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Aug 2018 23:34:11 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Cc: 32194@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 05 01:34:06 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 1fm63i-0002vu-Ac for geb-bug-gnu-emacs@m.gmane.org; Sun, 05 Aug 2018 01:34:06 +0200 Original-Received: from localhost ([::1]:56590 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fm65m-0006Ds-RW for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Aug 2018 19:36:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fm65f-0006Da-Mb for bug-gnu-emacs@gnu.org; Sat, 04 Aug 2018 19:36:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fm65a-0007np-Nq for bug-gnu-emacs@gnu.org; Sat, 04 Aug 2018 19:36:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36171) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fm65a-0007nj-Hx for bug-gnu-emacs@gnu.org; Sat, 04 Aug 2018 19:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fm65a-0001sB-9E for bug-gnu-emacs@gnu.org; Sat, 04 Aug 2018 19:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Aug 2018 23:36:02 +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.15334257427169 (code B ref 32194); Sat, 04 Aug 2018 23:36:02 +0000 Original-Received: (at 32194) by debbugs.gnu.org; 4 Aug 2018 23:35:42 +0000 Original-Received: from localhost ([127.0.0.1]:41189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fm65F-0001rY-MX for submit@debbugs.gnu.org; Sat, 04 Aug 2018 19:35:41 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:39430) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fm65D-0001rL-K7 for 32194@debbugs.gnu.org; Sat, 04 Aug 2018 19:35:40 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7C7B0160CF7; Sat, 4 Aug 2018 16:35:33 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id aUdYEFZ-q6qo; Sat, 4 Aug 2018 16:35:32 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8D44D160D70; Sat, 4 Aug 2018 16:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GTqZmHjzL45x; Sat, 4 Aug 2018 16:35:32 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 42BBE160CF7; Sat, 4 Aug 2018 16:35:32 -0700 (PDT) Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECH In-Reply-To: <83a7q2t9zh.fsf@gnu.org> Content-Language: en-US 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:149265 Archived-At: 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. >=20 > 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 compatib= le with=20 the glibc API and performing significantly better. The glibc code is hair= y and=20 was written by an expert and its behavior would be hard to replicate. In = the=20 unlikely event that there is such a platform and it requires unusual flag= s, that=20 platform's builder can simply configure with the appropriate CFLAGS, LDLI= BS,=20 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? >=20 > 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=20 they do we can add Gnulib-based substitutes for the missing prerequisites= . I=20 already did that in Bug#32194#5; you suggested in Bug#32194#8 point (3) t= hat we=20 not bother with it, though, and this seemed like good idea so that's what= in the=20 current proposal. If the idea doesn't work it will be easy to go back to = the=20 approach in Bug#32194#5 (as I recall it's a simple change to admin/merge-= gnulib=20 followed by turning the crank). >> (malloc, realloc, free): Do not redefine. Adjust all callers >> to use xmalloc, xrealloc, xfree instead. >=20 > 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 Ema= cs, so=20 this is just code simplification, not a real change. The Emacs regex code= needs=20 to use xmalloc to do the right thing with memory exhaustion and to do mem= ory=20 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 ol= d=20 Fedora 28 x86-64 platform with 'make TAGS CFLAGS=3D'-O2 -march=3Dnative"'= in the=20 Emacs src directory, user+system time grows from 0.55 to 0.59 seconds, ab= out a=20 10% slowdown. It grows about 10% more, to 0.64 seconds, if I use the=20 system-installed regex library instead of the Gnulib-supplied one. I don'= t view=20 an extra tenth of a second as a glitch big enough to be worth investigati= ng.