Re: Potential GC-related problems in compose_chars_in_text

[Richard M. Stallman]

    > I think that the cleanest thing to do, in loops that don't need to be
    > as fast as possible, is avoid saving addresses of string data at all.

    I agree.  But, I think display_mode_element is the place
    that have to be as fast as possible.

I would think that it doesn't take up very much of Emacs cpu time,
and that a small slowdown there would be insignificant.  That function
calls subroutines that do a lot of work.

Looking at the new code, I think it is correct.  It is correct because
the code consists of many alternatives, and each one does only a
single nontrivial thing and then gets to the end, where lisp_string
and this are updated.  But it seems a bit fragile to me.
What if some branch is later changed to do two things that could
relocate?  Then it would have a bug again.

So I think I will still put in the change I made.


The reason I worry about the patch you made is that it depends
on knowing exactly where the relocation might occur.