[Top][All Lists]

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

Re: Feature freeze on October 1

From: Stefan Monnier
Subject: Re: Feature freeze on October 1
Date: Thu, 27 Sep 2012 08:57:23 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

>> > Your memory is fine.  The workaround code is in ralloc.c and in
>> > maybe_unify_char.  But since we still call maybe_unify_char in
>> > decode_char, I don't think we can remove those workarounds yet, can
>> > we?
>> Are there calls to decode_char which aren't prepared to run Elisp code?
> maybe_unify_char doesn't run Elisp code but allocates a Lisp
> vector and a Lisp chartable via load_charset.

Oh, indeed, I see it should not be able to run arbitrary Elisp, so the
damage is a bit more limited.

> And I'm not sure that all calls to decode_char are prepared
> to buffer/string relocation.

String relocation only happens during GC, which normally only happens
during Elisp evaluation, so that shouldn't be an issue.
But, yes, it seems that ccl.c and maybe coding.c both have uses of
decode_char where buffer relocation can cause problems
(CODING_DECODE_CHAR seems to try and handle it explicitly, but I'm not
sure it's sufficient).


reply via email to

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