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

[Chong Yidong <cyd@stupidchicken.com>]

Richard Stallman <rms@gnu.org> 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.