GNU bug report logs - #75322
SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: pipcet <at> protonmail.com, 75322 <at> debbugs.gnu.org
Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
Date: Sat, 04 Jan 2025 21:10:28 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: pipcet <at> protonmail.com,  75322 <at> debbugs.gnu.org
> Date: Sat, 04 Jan 2025 19:35:04 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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.

Sorry, I don't have a clear idea what that means.  When can we use
SAFE_NALLOCA and friends? when can we or must we use SAFE_ALLOCA_LISP?
What are the considerations? etc. etc.

I believe you that you have a clear idea, but we need all of us have a
clear idea, and we should probably write that up somewhere once we do.

> > 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 :-).

I'm sorry to hear that, because I think it's important to have you on
board in this discussion.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.