Re: Feature freeze on October 1

[Kenichi Handa]

In article <address@hidden>, Stefan Monnier <address@hidden> writes:

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

I see.

> But, yes, it seems that ccl.c and maybe coding.c both have uses of
> decode_char where buffer relocation can cause problems

In ccl.c, ccl_driver uses DECODE_CHAR, and ccl_driver itself
has no problem because it doesn't uses a pointer into
buffer/string.  But, I noticed that the callers of that
function in coding.c (decode_coding_ccl and
encode_coding_ccl) has to prepare for buffer relocation.
I've just installed a fix.

> (CODING_DECODE_CHAR seems to try and handle it explicitly, but I'm not
> sure it's sufficient).

At least, it should be sufficient for pointers used by code
conversion routines.  Isn't it?

---
Kenichi Handa
address@hidden