[Top][All Lists]

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

Re: [BUG] Regexp compiler, problem with character classes

From: Chong Yidong
Subject: Re: [BUG] Regexp compiler, problem with character classes
Date: Fri, 15 Sep 2006 11:13:39 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Richard Stallman <address@hidden> 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

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

> 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.

reply via email to

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