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

[Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

"Eli Zaretskii" <eliz@gnu.org> writes:
> we should be able to use without restrictions static variables whose
> values are Lisp strings.

Without staticpro?  That makes no sense whatsoever to me.  It's not true
for either garbage collector.  Do you expect MPS to scan the entire
data/bss segment ambiguously?

>> Which might be in a register and not survive until GC is triggered.
>
> A Lisp_Object variable will survive.  Its pointer will be updated if
> needed to point to the new location of the data.  Thus, using the

MPS never changes the value of an automatic variable.

> Lisp_Object variable is always safe, but the pointer to its data must
> be updated after a potential GC.
>
>> >> > The below is indeed unsafe:
>> >> >
>> >> >   char *p = SDATA (unmarked);
>> >> >   ... trigger GC here ...
>> >> >   puts (p);
>> >>
>> >> Right now, that's safe for MPS, but not for the old GC, correct?
>> >
>> > If GC moves string data, then it is not safe, period.  Does MPS move
>> > string data?
>>
>> MPS does not move string data if there is a stack variable pointing to
>> it.  It does in other cases.  This is why it's safe for MPS.  The old
>> GC, IIUC, is less forgiving.
>
> The conclusion is that the above is NOT safe, because in some cases
> the data could move.  Which was what I said from the get-go.

The conclusion is incorrect.  The code is safe if MPS is in use, and we
rely on that.

The idea behind MPS is that you write code as above, which is safe when
MPS is in use, rather than attempting to avoid GC, which is fragile at
best (see call_process) and impossible in multi-threaded systems.  We
have to avoid the old GC in the !HAVE_MPS build, but with the MPS
collector, there is no need (and no way) to avoid GC here.

You seem to fundamentally disagree with me about how MPS works.  We need
to resolve that difference one way or another before we can continue any
GC-related discussions.

Pip