Re: Feature freeze on October 1

[Stefan Monnier]

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


        Stefan