From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: [BUG] Regexp compiler, problem with character classes Date: Fri, 15 Sep 2006 11:13:39 -0400 Message-ID: <87odth17to.fsf@stupidchicken.com> References: <87fyeu5937.fsf@stupidchicken.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1158333160 1548 80.91.229.2 (15 Sep 2006 15:12:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 15 Sep 2006 15:12:40 +0000 (UTC) Cc: emacs-devel@gnu.org, bojohan+mail@dd.chalmers.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 15 17:12:37 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GOFMB-0000qL-CM for ged-emacs-devel@m.gmane.org; Fri, 15 Sep 2006 17:11:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GOFMA-0003tb-SP for ged-emacs-devel@m.gmane.org; Fri, 15 Sep 2006 11:11:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GOFM1-0003tE-1Z for emacs-devel@gnu.org; Fri, 15 Sep 2006 11:11:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GOFLz-0003sl-Vp for emacs-devel@gnu.org; Fri, 15 Sep 2006 11:11:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GOFLz-0003se-Q5 for emacs-devel@gnu.org; Fri, 15 Sep 2006 11:11:43 -0400 Original-Received: from [18.19.1.138] (helo=cyd) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GOFOB-0002FJ-0K; Fri, 15 Sep 2006 11:13:59 -0400 Original-Received: by cyd (Postfix, from userid 1000) id A67464E3DF; Fri, 15 Sep 2006 11:13:39 -0400 (EDT) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Fri\, 15 Sep 2006 10\:29\:37 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:59875 Archived-At: Richard Stallman writes: > + void > + clear_regexp_cache () > + { > + int i; > + > + BLOCK_INPUT; > + for (i = 0; i < REGEXP_CACHE_SIZE; ++i) > + searchbufs[i].regexp = Qnil; > + UNBLOCK_INPUT; > + } > > 1. That leaks the memory in the compiled regexps. Are you sure? AFAICT, re_compile_pattern automagically manages the memory allocated in each re_pattern_buffer struct, based on the value of bufp->allocated and bufp->buffer. If we reset searchbuf->regexp to Qnil, that means that cache element can be used to store a compiled regexp, and the memory used by any compiled regexp (i.e., the re_pattern_buffer) previously existing in that cache element is reused. This seems to be the existing practice in search.c: the cache elements are initialized in syms_of_search as for (i = 0; i < REGEXP_CACHE_SIZE; ++i) { searchbufs[i].buf.allocated = 100; searchbufs[i].buf.buffer = (unsigned char *) xmalloc (100); ... searchbufs[i].regexp = Qnil; ... } When compile_pattern is called with an uncached regexp, it tries to cache it in an empty cache element (i.e., one with a nil `regexp' entry). If no cache elements are empty, it uses the oldest cache element by resetting its `regexp' entry and passing it along to re_compile_pattern. > 2. I don't see a reason for BLOCK_INPUT. > I don't think anything in a signal handler can compile a regexp. That's probably true.