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

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 75322@debbugs.gnu.org
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Sat, 04 Jan 2025 05:40:09 +0100
>> 
>> And today I see you reverted that commit. Is there something wrong with
>> it? I couldn't see something wrong, and for me VALUE(no root) >
>> VALUE(exact) VALUE(ambig).
>
> That's my fault.  I asked to post the patch and discuss it before
> committing, as these are delicate issues where I prefer that we all
> are on the same page before changing this code.

Ah okay, that explains it, I missed that discussion, sorry.

>> WRT Lisp_Object allocas, please tell if I should do that.
>
> Let's discuss this on a case by case basis.  Not all uses of alloca
> are the same or have the same requirements and restrictions.

Okay. For the SDATA case, I find Pip's commit does the right thing. It
uses xstrdup for the strings and makes sure these are freed later by
registering them in one of the special specpdl entries that exist for
that purpose (record_unwind_protect_ptr). Works with both GCs, is always
safe, I don't see disadvantages, and we don't have to check if GC runs
or not and compact strings (old) or moves string data around (igc).

For the Lisp_Object cases, I strongly suspect that these cases are an
oversight and were left over when SAFE_ALLOCA_LISP was introduced. The
reason for introducing SAFE_ALLOCA_LISP is, IMO, what Pip said (old GC):
to make sure that the Lisp_Objects are marked, via specpdl stack entries
again, when the specpdl stack(s) are marked. Not doing that looks
definitely wrong. Replacing the other ALLOCA macros that are currently
used for holding Lisp_Objects with SAFE_ALLOCA_LISP would solve things
for both GCs.