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

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com,  75322@debbugs.gnu.org
> Date: Sun, 05 Jan 2025 09:19:17 +0100
> 
> I'd grep for SAFE_NALLOCA, and for each occurrence, see what is stored
> in the memory allocated.

Is only SAFE_NALLOCA a potential problem?  What about the other
members of the SAFE_*ALLOC* family?

> If that is a reference to MPS-allocated memory
> (a pointer or Lisp_Object), it should be changed, because it then hides
> references from MPS in malloc'd memory. Or can hide, to be more precise,
> in the case it doesn't use alloca.

Does using igc_xnmalloc_ambig have any significant adverse effect on
GC?  Like makes it slower or forces it to scan more memory?  Because
if we make SAFE_NALLOCA do this by default, there could be quite a lot
more such ambiguous roots by the time GC starts.

If this could impact performance or has some other adverse effects,
I think I'd prefer to have a new argument to SAFE_NALLOCA telling it
whether to call igc_xnmalloc_ambig, and we will then need to audit our
code to use that argument where what's stored in the memory it
allocates could be a Lisp object.  This is more error-prone, but
performance does count, especially where it comes to GC.

> I think the performance impact of that is negligible because this
> path is only executed when SAFE_ALLOCA does not use alloca.

MAX_ALLOCA is only 16KB (and Paul Eggert says it's dangerous to make
it significantly larger), so I'm not sure your assumption about
negligible performance impact is necessarily correct.