bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  75322@debbugs.gnu.org
>> Date: Sat, 04 Jan 2025 16:34:15 +0100
>> 
>> I'm entering a state of confusion again, as usual in this discussion.
>> Can we _pretty please_ just do the xstrdup thing, and forget about it?
>
> We could do that, but what does this mean for our protocol of using
> data from Lisp objects in libc and system calls?  Does it mean we
> cannot use SAFE_ALLOCA?  Does it mean we must always xstrdup every
> string and xmalloc every other object before calling some system API?
> Are Lisp strings safe when GC can strike, or aren't they?  What about
> Lisp vectors?  Etc. etc.
>
> We must figure out what are the safe and sound rules for doing this
> with MPS, like we had with the old GC.  Otherwise, we will be unable
> to write correct and sound code, and we'll be unable to audit code
> written by others.
>
> Right now, it doesn't seem to me like we have a clear idea of what's
> permitted and what's unsafe.  

I'd say I have a clear idea.

> We are still arguing whether GC moves Lisp strings and what exactly
> does that mean. We still don't understand well enough what, if
> anything, are the problems with SAFE_ALLOCA and its ilk. 

I can't believe you say that. We talked about why xmalloc'd memory
has to be a root if it contains references. SAFE_NALLOCA uses xnmalloc.
Safe_ALLOCA_LISP does things differently.

> We just established that ENCODE_FILE and ENCODE_SYSTEM can trigger GC,
> and didn't yet review the affected code. And there are many more
> places and calls to consider (e.g., do you know that redisplay could
> trigger GC when it calls character composition?).
>
> If we don't consider this stuff, if we just "do the xstrdup thing and
> forget about it", how can we continue cleaning up the igc branch and
> making its code more stable and reliable?  It doesn't sound wise to
> me.

I'll bow out of this discussion, sorry. This time for real :-).