all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org
Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
Date: Sat, 04 Jan 2025 21:10:28 +0200	[thread overview]
Message-ID: <86frlybdjv.fsf@gnu.org> (raw)
In-Reply-To: <m2jzbajulj.fsf@gmail.com> (message from Gerd Möllmann on Sat, 04 Jan 2025 19:35:04 +0100)

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





  reply	other threads:[~2025-01-04 19:10 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-03 17:20 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
2025-01-03 19:55 ` Gerd Möllmann
2025-01-03 20:34   ` Gerd Möllmann
2025-01-03 20:48     ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-04  4:40       ` Gerd Möllmann
2025-01-04  7:57         ` Eli Zaretskii
2025-01-04  8:47           ` Gerd Möllmann
2025-01-04  9:56             ` Eli Zaretskii
2025-01-04 10:20               ` Gerd Möllmann
2025-01-05 13:30                 ` Eli Zaretskii
2025-01-05 14:11                   ` Gerd Möllmann
2025-01-05 17:45                     ` Eli Zaretskii
2025-01-05 18:17                       ` Gerd Möllmann
2025-01-05 19:07                         ` Eli Zaretskii
2025-01-05 20:04                           ` Gerd Möllmann
2025-01-05 20:24                             ` Eli Zaretskii
2025-01-06  3:57                               ` Gerd Möllmann
2025-01-06  8:25                                 ` Gerd Möllmann
2025-01-06 14:07                                 ` Eli Zaretskii
2025-01-05 21:15                           ` Daniel Colascione
2025-01-06 12:59                             ` Eli Zaretskii
2025-01-06 14:48                               ` Daniel Colascione
2025-01-06 15:12                                 ` Eli Zaretskii
2025-01-06 15:27                                   ` Daniel Colascione
2025-01-05 21:01                     ` Daniel Colascione
2025-01-05 23:28                       ` Daniel Colascione
2025-01-06 13:26                         ` Eli Zaretskii
2025-01-06 15:08                           ` Daniel Colascione
2025-01-06  4:23                       ` Gerd Möllmann
2025-01-04 11:41               ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-04 11:29         ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-04 12:17           ` Gerd Möllmann
2025-01-04  7:00     ` Eli Zaretskii
2025-01-04  7:17       ` Gerd Möllmann
2025-01-04  8:23         ` Eli Zaretskii
2025-01-04  8:58           ` Gerd Möllmann
2025-01-04 11:08       ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-04 13:47         ` Eli Zaretskii
2025-01-04 14:13           ` Gerd Möllmann
2025-01-04 15:26           ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-04 15:34             ` Gerd Möllmann
2025-01-04 18:19               ` Eli Zaretskii
2025-01-04 18:35                 ` Gerd Möllmann
2025-01-04 19:10                   ` Eli Zaretskii [this message]
2025-01-04 19:24                     ` Gerd Möllmann
2025-01-04 18:02             ` Eli Zaretskii
2025-01-04 19:32               ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-04 20:31                 ` Eli Zaretskii
2025-01-04 21:15                   ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-05  8:23                     ` Eli Zaretskii
2025-01-05  9:04                       ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-05  9:32                         ` Eli Zaretskii
2025-01-05  9:47                           ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-05 11:04                             ` Eli Zaretskii
2025-01-06 15:54                               ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-06 19:16                                 ` Gerd Möllmann
2025-01-08  3:46                                   ` Gerd Möllmann
2025-01-05  6:32 ` Gerd Möllmann
2025-01-05  6:59   ` Gerd Möllmann
2025-01-05 10:21     ` Eli Zaretskii
2025-01-05 10:30       ` Gerd Möllmann
2025-01-05 10:35         ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-05 10:45           ` Gerd Möllmann
2025-01-05 11:29         ` Eli Zaretskii
2025-01-05 11:37           ` Gerd Möllmann
2025-01-05 12:15             ` Eli Zaretskii
2025-01-05 13:21               ` Gerd Möllmann
2025-01-05 17:31                 ` Eli Zaretskii
2025-01-05 17:49                   ` Gerd Möllmann
2025-01-05 18:42                     ` Eli Zaretskii
2025-01-05 19:02                       ` Gerd Möllmann
2025-01-05  7:48   ` Eli Zaretskii
2025-01-05  8:19     ` Gerd Möllmann
2025-01-05 10:33       ` Eli Zaretskii
2025-01-05 10:40         ` Gerd Möllmann
2025-01-05 11:21           ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-05 11:27             ` Gerd Möllmann
2025-01-05 11:49             ` Paul Eggert
2025-01-06  6:26           ` Gerd Möllmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86frlybdjv.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=75322@debbugs.gnu.org \
    --cc=gerd.moellmann@gmail.com \
    --cc=pipcet@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.