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: pipcet@protonmail.com,  75322@debbugs.gnu.org
>> Date: Sun, 05 Jan 2025 19:17:37 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > OK, but in most, if not all of these cases, the objects are referenced
>> > from the stack.  For example, in the above fragment, the args[] array
>> > is on the stack.  Right?
>> 
>> That args is a parameter
>> 
>>   call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd,
>> 
>> So just from this I see only args itself on the stack, not args[0],
>> args[1] and so on. I would have to look at all callers to determine
>> that. Not good enough in my book.
>
> So what, we will now need to copy every args[] into a Lisp vector
> created by SAFE_ALLOCA_LISP, or xstrdup all of them, and do it in
> each and every function that gets the args[] array, all the way down
> to where the array is finally used (because usually we have 3 or 4
> nested levels that pass args[] to one another)?  That's insane!
>
>> > What does it mean in detail "the object may move"?  A Lisp object is a
>> > tagged pointer.  Do you mean the pointer should no point to a
>> > different address, i.e. the value of a Lisp object as a number should
>> > change to still be valid?  
>> 
>> Exactly. Unless an ambiguous reference prevents the copying that can
>> happen.
>
> How can we possibly make sure this works reliably and safely??  For
> each variable we have in every function, we will need to analyze
> whether the variable is
>
>   . an automatic variable
>   . a static variable that is protected by someone
>   . a global variable that is protected by someone
>   . a result of dereferencing a pointer that is somehow protected
>
> etc. etc., where "protected by someone" means that it is a descendant
> of some staticpro, or of some root, or...
>
> And if we cannot prove to ourselves that one of the above happens,
> then we'd need to force a copy of the variable to be on the stack?
>
> Does this sound practical?
>
> If this is the price of using MPS, and I'm not missing something
> obvious, then it sounds like we should run away from MPS, fast.
> Because we will sooner or later have to rewrite every single line of
> code we ever wrote.

I'm bowing out again. It's not worth it.