GNU bug report logs - #65796
dynamic module non_local_exit_get overwrites exit signals

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Xinyang Chen <chenxinyang99@HIDDEN>; Keywords: patch; dated Thu, 7 Sep 2023 04:59:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.
Added tag(s) patch. Request was from Stefan Kangas <stefankangas@HIDDEN> to control <at> debbugs.gnu.org. Full text available.

Message received at 65796 <at> debbugs.gnu.org:


Received: (at 65796) by debbugs.gnu.org; 25 Feb 2025 14:43:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 25 09:43:36 2025
Received: from localhost ([127.0.0.1]:45531 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tmw9n-0002PG-V8
	for submit <at> debbugs.gnu.org; Tue, 25 Feb 2025 09:43:36 -0500
Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:38308)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <p.stephani2@HIDDEN>)
 id 1tmw9k-0002Ov-6u
 for 65796 <at> debbugs.gnu.org; Tue, 25 Feb 2025 09:43:33 -0500
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5dc191ca8baso1383531a12.1
 for <65796 <at> debbugs.gnu.org>; Tue, 25 Feb 2025 06:43:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1740494606; x=1741099406; darn=debbugs.gnu.org;
 h=references:to:cc:in-reply-to:date:subject:mime-version:message-id
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=YSj/WJe4wCcaAeKnkTJ0byjGADgMEml+hk2AlQ/peqA=;
 b=UYtZcSTWOaIAtHRh40bofYgqeYsJC4KLjB7yTzDY5L2UyYSgujkcHLcVF+nEp+ZcpZ
 9T1X8er2unT9fhRDBOO5K+o7XB9ydmvhiYQpbcnZO7Fz+3YBAUU3IyvJiflWTsrhWN5Z
 QgvjYp2LYdMS5C2Xm3264rkSh4ctvBO8EZwYAHU7qJff8ddrkUsfje9LzBVjG4GzQorz
 XIONHJgfTIyZS/aoF5ZmZ/gf+SBU7wEFJrRiuDbm3J0oJT99teapDPmcwa+Uw7eGDwp0
 pjWJ4BmZf6IGmAPiSNf0MU0FuuAU+BRPCrSQjuUFL0yHZuo+yecRCTISX/Cjfd4v3nNp
 Qe/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1740494606; x=1741099406;
 h=references:to:cc:in-reply-to:date:subject:mime-version:message-id
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=YSj/WJe4wCcaAeKnkTJ0byjGADgMEml+hk2AlQ/peqA=;
 b=WZmP2FONihTQ476SV9MyykrQnH+ZBNe2Bj738OukZArxWmIFPLZhtVMwPskAKWav0a
 Vn/lEB0yc4c8SCmwWE6yFjqjofrm9Bj/dV94v+mqyLRonPtfFmHEIUSePgvQ8YuRmqZk
 qYF19vdXi8tm58LUr8nkFDP+OAvxUV4aRh+H+dFSp9dRUjgTCWcGtJLaicqcAbprg3yd
 yawsklnsjCuFkeD+ccSQSk4Eu9nCIwXauKcN3y9PB9lW6XlSNL+Ll13/ttTVAfUF/PJo
 mPkGrp2AwDkaD8Dfznzq51lidxT3HfcRMT57opKH6ym1Hx2ism7WjOqZOgUyGvzZwVOL
 iyyA==
X-Forwarded-Encrypted: i=1;
 AJvYcCXf6rgAhMQ2rtJByZM0N7lm0aJhaecuF3aNDTMK4R6lqfs6kfjaewEcFw5TVSkTcXs5aJDgSg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxW4VNJD/e71lyo0dUewXlWHSyhApYTYZz9lWylO4NwEfUFaGYv
 Ea3MASfzg9h6dJP/0wFg2vSG5YKCZ2WLzp8bvJ1cLspszRPBn7tI
X-Gm-Gg: ASbGnctcTuSNUYmG3S8Pad/PGRBN1T9u3HEsOv5BYsF2Ne/37LiDsPrGkjEbSRnwurQ
 KmMNuEhMTLQlYMFQENkSxGdgx+OByMuHp7umavgXHCzhqgmZ1coHG6Wp4TLDkKAOeQRwTpCjLS/
 mOpwEKNTJgr5Tl5NjP+X+EbLOTlYxiTu0cdHV/MjoYyZDLvagBxXLZTomuVUcXDAsSX49HNRBqu
 xZNIOmuvlVeEHMHbsRYvEjFvJNqS/dtniy/4lVWsHEhBDArpjo0BHZixhG5ozeN8apPEG9ZnROJ
 hq/PAbuDY7QVaEl+vOcjb3VJWryLhNHCw0EgHgO38QZWx438ucqiROit
X-Google-Smtp-Source: AGHT+IEUprmnwKKLZGVIoQqQOTvV5hI21ySppO+ysAb6MJ8/6JNRk13HI9ZScpwz1CHJuyJjqs/H/Q==
X-Received: by 2002:a05:6402:2551:b0:5e0:7afe:4e12 with SMTP id
 4fb4d7f45d1cf-5e0b724c6f8mr6610225a12.10.1740494605566; 
 Tue, 25 Feb 2025 06:43:25 -0800 (PST)
Received: from smtpclient.apple ([2001:a61:3a5d:f801:a9d8:55fa:e6d8:4777])
 by smtp.gmail.com with ESMTPSA id
 4fb4d7f45d1cf-5e492120418sm898675a12.14.2025.02.25.06.43.23
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 25 Feb 2025 06:43:24 -0800 (PST)
From: Philipp Stephani <p.stephani2@HIDDEN>
Message-Id: <23B6FA1A-CFCD-43DD-B425-AC236990335C@HIDDEN>
Content-Type: multipart/mixed;
 boundary="Apple-Mail=_19C77EA4-DF56-4F6A-838F-A39D1668C8F8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Subject: Re: bug#65796: dynamic module non_local_exit_get overwrites exit
 signals
Date: Tue, 25 Feb 2025 15:43:13 +0100
In-Reply-To: <CANnQ9XagArsb_Fcj6kkBhnxQNNXqTxv=cU34hy33ynnoU7WojQ@HIDDEN>
To: Xinyang Chen <chenxinyang99@HIDDEN>
References: <CANnQ9XZWvWTzcSvh+wVbTygOHtL4oYT9JZmBYK1SGSO9FCHaNQ@HIDDEN>
 <8334zq1mx6.fsf@HIDDEN>
 <CAP-RRPuCAGeyV+aZR5E338Wb5PMWOKqyT6Wt+nBT-yzPGgtP7g@HIDDEN>
 <CANnQ9XagArsb_Fcj6kkBhnxQNNXqTxv=cU34hy33ynnoU7WojQ@HIDDEN>
X-Mailer: Apple Mail (2.3826.400.131.1.6)
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 65796
Cc: Philipp Stephani <phst@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 Daniel Colascione <dancol@HIDDEN>, 65796 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)


--Apple-Mail=_19C77EA4-DF56-4F6A-838F-A39D1668C8F8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Am 29.01.2025 um 18:52 schrieb Xinyang Chen <chenxinyang99@HIDDEN>:
>=20
> This is still a problem.
>=20
> Using a user buffer will require gc-protecting it and thus a major =
overhaul, so I think it's not a good idea.

Yeah, I figured out that approach is a dead end meanwhile.

>=20
> IMO what we should do is: if we fail to allocate, we discard the =
original signal and replace it with an OOM signal (pointing to constants =
so requiring no allocation).

Yeah, that's a good idea, thanks for bringing it up.  I've attached a =
patch to that effect.

> Perhaps we should make a new field in emacs_funcall_exit for OOM, or =
we can just use emacs_funcall_exit_signal.

My patch does the latter: Adding a new enum value risks UB if callers =
don't have a default case in their switch statements, behavior in OOM =
situations is best-effort anyway, and very careful callers can still =
compare the returned error symbol against the (documented) OOM symbol.

>=20
> Alternatively, make a copy_emacs_value function that allows the user =
to copy the signal out, returning NULL to let the caller know that an =
allocation failure occurred.

I also considered that, but it puts too much onus on the module authors =
to deal with a situation that effectively never happens.

>=20
>=20
>=20
> On Thu, Sep 7, 2023 at 5:24=E2=80=AFAM Philipp Stephani =
<phst@HIDDEN> wrote:
> On Thu, 7 Sept 2023 at 09:07, Eli Zaretskii <eliz@HIDDEN> wrote:
> >
> > > From: Xinyang Chen <chenxinyang99@HIDDEN>
> > > Date: Wed, 6 Sep 2023 18:52:14 -0400
> > >
> > > Currently `module_non_local_exit_get` returns pointers to fields
> > > in emacs_env_private:
> > > ```
> > >   if (p->pending_non_local_exit !=3D emacs_funcall_exit_return)
> > >     {
> > >       *symbol =3D &p->non_local_exit_symbol;
> > >       *data =3D &p->non_local_exit_data;
> > >     }
> > > ```
> > > this means that if one tries to:
> > > ```
> > > funcall(...);
> > > non_local_exit_get(&s1, &d1);
> > > funcall(...);
> > > non_local_exit_get(&s2, &d2);
> > > non_local_exit_signal(s1, d1);
> > > ```
> > > you would signal the second error, instead of the first error (I =
expected
> > > this to happen).
> > > It seems to me that `module_non_local_exit_get` should
> > > `allocate_emacs_value` instead.
> >
> > Philipp, Daniel: any comments?
>=20
> Nice find!
> We can't use allocate_emacs_value here because non_local_exit_get has
> to work in OOM situations and can never fail. What we could do here is
> e.g.:
> - Document the current behavior, stating that the emacs_value objects
> returned from non_local_exit_get are ephemeral. I'm not a huge fan of
> this because it makes non_local_exit_get behave different from all
> other functions.
> - Provide an alternative non_local_exit_copy that copies the 2
> Lisp_Objects into an opaque buffer supplied by the user (plus a way to
> determine the buffer size). That way we shift the responsibility of
> dealing with allocation failures to the user.
> - Attempt to allocate a new emacs_value, fall back to the current
> behavior if that fails. I don't really like that option either because
> it doesn't solve the initial problem in all cases (so users still need
> to deal with it), but makes both the interface and the implementation
> more complex.
> - Crash if we can't allocate memory. That has been rejected in other =
cases.
>=20
> >
> > Btw, the non_local_exit_get function is currently not documented in
> > the ELisp manual; should it be?
>=20
> At least in Emacs 29 I see it documented ("Module Nonlocal" node).



--Apple-Mail=_19C77EA4-DF56-4F6A-838F-A39D1668C8F8
Content-Disposition: attachment;
	filename=0001-Don-t-overwrite-non-local-exit-symbol-and-data-Bug-6.patch
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="0001-Don-t-overwrite-non-local-exit-symbol-and-data-Bug-6.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=203f3cf20a405a299232be394aed304d37ef80a68c=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20Philipp=20Stephani=20<p.stephani2@HIDDEN>=0A=
Date:=20Thu,=2030=20Jan=202025=2016:12:49=20+0100=0ASubject:=20[PATCH]=20=
Don't=20overwrite=20non-local=20exit=20symbol=20and=20data=20=
(Bug#65796).=0A=0AThe=20previous=20approach=20would=20incorrectly=20=
invalidate=20the=20returned=20module=0Avalues=20if=20another=20non-local=20=
exit=20occurred=20while=20dealing=20with=20a=20non-local=0Aexit.=20=20=
See=20Bug#65796.=20=20Instead,=20allocate=20the=20values=20from=20the=20=
usual=0Aenvironment=20storage,=20and=20return=20statically-allocated=20=
objects=20if=20that=0Afails.=0A=0A*=20src/emacs-module.c=20(struct=20=
emacs_env_private):=20Turn=20non-local=20exit=0Asymbol=20and=20data=20=
into=20normal=20Lisp=20objects.=0A(initialize_environment):=20Initialize=20=
them.=0A(mark_module_environment):=20Prevent=20them=20from=20being=20=
garbage-collected.=0A(module_signal_or_throw,=20=
module_non_local_exit_signal_1)=0A(module_non_local_exit_throw_1):=20=
Adapt=20uses.=0A(value_to_lisp):=20No=20longer=20scan=20for=20them=20=
with=20module=20assertions=20enabled.=0A(module_out_of_memory_signal,=20=
module_out_of_memory_data):=20New=0Astatically-allocated=20module=20=
values=20to=20return=20in=20case=20of=20allocation=0Afailure.=0A=
(syms_of_module):=20Initialize=20them.=0A(module_non_local_exit_get):=20=
Allocate=20module=20values=20normally.=20=20If=20that=0Afails,=20return=20=
statically-allocated=20values.=0A=0A*=20doc/lispref/internals.texi=20=
(Module=20Nonlocal):=20Document=20new=20behavior.=0A---=0A=20=
doc/lispref/internals.texi=20|=20=206=20+++-=0A=20src/emacs-module.c=20=20=
=20=20=20=20=20=20=20|=2063=20++++++++++++++++++++++++++------------=0A=20=
2=20files=20changed,=2048=20insertions(+),=2021=20deletions(-)=0A=0Adiff=20=
--git=20a/doc/lispref/internals.texi=20b/doc/lispref/internals.texi=0A=
index=20ee1fcbbbd68..a8b9ea88f7f=20100644=0A---=20=
a/doc/lispref/internals.texi=0A+++=20b/doc/lispref/internals.texi=0A@@=20=
-2076,7=20+2076,11=20@@=20Module=20Nonlocal=0A=20tag=20symbol=20in=20=
@code{*@var{symbol}}=20and=20the=20@code{throw}=20value=20in=0A=20=
@code{*@var{data}}.=20=20The=20function=20doesn't=20store=20anything=20=
in=20memory=0A=20pointed=20by=20these=20arguments=20when=20the=20return=20=
value=20is=0A-@code{emacs_funcall_exit_return}.=0A=
+@code{emacs_funcall_exit_return}.=20=20If=20the=20function=20fails=20to=20=
allocate=0A+storage=20for=20@var{symbol}=20or=20@var{data},=20it=20=
stores=20a=20value=20representing=0A+the=20symbol=20=
@code{module-out-of-memory}=20in=20@code{*@var{symbol}},=20stores=20a=0A=
+value=20representing=20@code{nil}=20in=20@code{*@var{data}},=20and=20=
returns=0A+@code{emacs_funcall_exit_signal}.=0A=20@end=20deftypefn=0A=20=0A=
=20You=20should=20check=20nonlocal=20exit=20conditions=20where=20it=20=
matters:=20before=20you=0Adiff=20--git=20a/src/emacs-module.c=20=
b/src/emacs-module.c=0Aindex=200a67433ec70..ab6b900df8d=20100644=0A---=20=
a/src/emacs-module.c=0A+++=20b/src/emacs-module.c=0A@@=20-167,7=20+167,7=20=
@@=20Copyright=20(C)=202015-2025=20Free=20Software=20Foundation,=20Inc.=0A=
=20=20=20/*=20Dedicated=20storage=20for=20non-local=20exit=20symbol=20=
and=20data=20so=20that=0A=20=20=20=20=20=20storage=20is=20always=20=
available=20for=20them,=20even=20in=20an=20out-of-memory=0A=20=20=20=20=20=
=20situation.=20=20*/=0A-=20=20struct=20emacs_value_tag=20=
non_local_exit_symbol,=20non_local_exit_data;=0A+=20=20Lisp_Object=20=
non_local_exit_symbol,=20non_local_exit_data;=0A=20=0A=20=20=20struct=20=
emacs_value_storage=20storage;=0A=20};=0A@@=20-500,6=20+500,9=20@@=20=
module_non_local_exit_clear=20(emacs_env=20*env)=0A=20=20=20=
env->private_members->pending_non_local_exit=20=3D=20=
emacs_funcall_exit_return;=0A=20}=0A=20=0A+static=20struct=20=
emacs_value_tag=20module_out_of_memory_symbol;=0A+static=20struct=20=
emacs_value_tag=20module_out_of_memory_data;=0A+=0A=20static=20enum=20=
emacs_funcall_exit=0A=20module_non_local_exit_get=20(emacs_env=20*env,=0A=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20emacs_value=20*symbol,=20emacs_value=20*data)=0A@@=20-507,12=20=
+510,23=20@@=20module_non_local_exit_get=20(emacs_env=20*env,=0A=20=20=20=
module_assert_thread=20();=0A=20=20=20module_assert_env=20(env);=0A=20=20=
=20struct=20emacs_env_private=20*p=20=3D=20env->private_members;=0A-=20=20=
if=20(p->pending_non_local_exit=20!=3D=20emacs_funcall_exit_return)=0A+=20=
=20enum=20emacs_funcall_exit=20ret=20=3D=20p->pending_non_local_exit;=0A=
+=20=20if=20(ret=20!=3D=20emacs_funcall_exit_return)=0A=20=20=20=20=20{=0A=
-=20=20=20=20=20=20*symbol=20=3D=20&p->non_local_exit_symbol;=0A-=20=20=20=
=20=20=20*data=20=3D=20&p->non_local_exit_data;=0A+=20=20=20=20=20=20=
emacs_value=20sym=0A+=09=3D=20allocate_emacs_value=20(env,=20=
p->non_local_exit_symbol);=0A+=20=20=20=20=20=20emacs_value=20dat=0A+=09=
=3D=20allocate_emacs_value=20(env,=20p->non_local_exit_data);=0A+=20=20=20=
=20=20=20if=20(sym=20=3D=3D=20NULL=20||=20dat=20=3D=3D=20NULL)=0A+=09{=0A=
+=09=20=20sym=20=3D=20&module_out_of_memory_symbol;=0A+=09=20=20dat=20=3D=20=
&module_out_of_memory_data;=0A+=09=20=20ret=20=3D=20=
emacs_funcall_exit_signal;=0A+=09}=0A+=20=20=20=20=20=20*symbol=20=3D=20=
sym;=0A+=20=20=20=20=20=20*data=20=3D=20dat;=0A=20=20=20=20=20}=0A-=20=20=
return=20p->pending_non_local_exit;=0A+=20=20return=20ret;=0A=20}=0A=20=0A=
=20/*=20Like=20for=20`signal',=20DATA=20must=20be=20a=20list.=20=20*/=0A=
@@=20-1185,11=20+1199,11=20@@=20module_signal_or_throw=20(struct=20=
emacs_env_private=20*env)=0A=20=20=20=20=20case=20=
emacs_funcall_exit_return:=0A=20=20=20=20=20=20=20return;=0A=20=20=20=20=20=
case=20emacs_funcall_exit_signal:=0A-=20=20=20=20=20=20xsignal=20=
(value_to_lisp=20(&env->non_local_exit_symbol),=0A-=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20value_to_lisp=20(&env->non_local_exit_data));=0A+=20=
=20=20=20=20=20xsignal=20(env->non_local_exit_symbol,=0A+=09=20=20=20=20=20=
=20=20env->non_local_exit_data);=0A=20=20=20=20=20case=20=
emacs_funcall_exit_throw:=0A-=20=20=20=20=20=20Fthrow=20(value_to_lisp=20=
(&env->non_local_exit_symbol),=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20value_to_lisp=20(&env->non_local_exit_data));=0A+=20=20=20=20=20=20=
Fthrow=20(env->non_local_exit_symbol,=0A+=09=20=20=20=20=20=20=
env->non_local_exit_data);=0A=20=20=20=20=20default:=0A=20=20=20=20=20=20=
=20eassume=20(false);=0A=20=20=20=20=20}=0A@@=20-1389,8=20+1403,8=20@@=20=
module_non_local_exit_signal_1=20(emacs_env=20*env,=20Lisp_Object=20sym,=0A=
=20=20=20if=20(p->pending_non_local_exit=20=3D=3D=20=
emacs_funcall_exit_return)=0A=20=20=20=20=20{=0A=20=20=20=20=20=20=20=
p->pending_non_local_exit=20=3D=20emacs_funcall_exit_signal;=0A-=20=20=20=
=20=20=20p->non_local_exit_symbol.v=20=3D=20sym;=0A-=20=20=20=20=20=20=
p->non_local_exit_data.v=20=3D=20data;=0A+=20=20=20=20=20=20=
p->non_local_exit_symbol=20=3D=20sym;=0A+=20=20=20=20=20=20=
p->non_local_exit_data=20=3D=20data;=0A=20=20=20=20=20}=0A=20}=0A=20=0A=
@@=20-1402,8=20+1416,8=20@@=20module_non_local_exit_throw_1=20(emacs_env=20=
*env,=20Lisp_Object=20tag,=0A=20=20=20if=20(p->pending_non_local_exit=20=
=3D=3D=20emacs_funcall_exit_return)=0A=20=20=20=20=20{=0A=20=20=20=20=20=20=
=20p->pending_non_local_exit=20=3D=20emacs_funcall_exit_throw;=0A-=20=20=20=
=20=20=20p->non_local_exit_symbol.v=20=3D=20tag;=0A-=20=20=20=20=20=20=
p->non_local_exit_data.v=20=3D=20value;=0A+=20=20=20=20=20=20=
p->non_local_exit_symbol=20=3D=20tag;=0A+=20=20=20=20=20=20=
p->non_local_exit_data=20=3D=20value;=0A=20=20=20=20=20}=0A=20}=0A=20=0A=
@@=20-1439,13=20+1453,6=20@@=20value_to_lisp=20(emacs_value=20v)=0A=20=20=
=20=20=20=20=20=20=20=20=20{=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=
const=20emacs_env=20*env=20=3D=20pdl->unwind_ptr.arg;=0A=20=20=20=20=20=20=
=20=20=20=20=20=20=20struct=20emacs_env_private=20*priv=20=3D=20=
env->private_members;=0A-=20=20=20=20=20=20=20=20=20=20=20=20/*=20The=20=
value=20might=20be=20one=20of=20the=20nonlocal=20exit=20values.=20=20=
Note=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20that=20we=20don't=20=
check=20whether=20a=20nonlocal=20exit=20is=20currently=0A-=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20pending,=20because=20the=20module=20might=20=
have=20cleared=20the=20flag=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20in=20the=20meantime.=20=20*/=0A-=20=20=20=20=20=20=20=20=20=20=20=20=
if=20(&priv->non_local_exit_symbol=20=3D=3D=20v=0A-=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20||=20&priv->non_local_exit_data=20=3D=3D=20v)=0A=
-=20=20=20=20=20=20=20=20=20=20=20=20=20=20goto=20ok;=0A=20=20=20=20=20=20=
=20=20=20=20=20=20=20if=20(value_storage_contains_p=20(&priv->storage,=20=
v,=20&num_values))=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20goto=20=
ok;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20++num_environments;=0A@@=20=
-1536,6=20+1543,8=20@@=20mark_module_environment=20(void=20*ptr)=0A=20{=0A=
=20=20=20emacs_env=20*env=20=3D=20ptr;=0A=20=20=20struct=20=
emacs_env_private=20*priv=20=3D=20env->private_members;=0A+=20=20=
mark_object=20(priv->non_local_exit_symbol);=0A+=20=20mark_object=20=
(priv->non_local_exit_data);=0A=20=20=20for=20(struct=20=
emacs_value_frame=20*frame=20=3D=20&priv->storage.initial;=20frame=20!=3D=20=
NULL;=0A=20=20=20=20=20=20=20=20frame=20=3D=20frame->next)=0A=20=20=20=20=
=20for=20(int=20i=20=3D=200;=20i=20<=20frame->offset;=20++i)=0A@@=20=
-1561,6=20+1570,8=20@@=20initialize_environment=20(emacs_env=20*env,=20=
struct=20emacs_env_private=20*priv)=0A=20=20=20=20=20}=0A=20=0A=20=20=20=
priv->pending_non_local_exit=20=3D=20emacs_funcall_exit_return;=0A+=20=20=
priv->non_local_exit_symbol=20=3D=20Qnil;=0A+=20=20=
priv->non_local_exit_data=20=3D=20Qnil;=0A=20=20=20initialize_storage=20=
(&priv->storage);=0A=20=20=20env->size=20=3D=20sizeof=20*env;=0A=20=20=20=
env->private_members=20=3D=20priv;=0A@@=20-1711,6=20+1722,18=20@@=20=
syms_of_module=20(void)=0A=20=20=20Vmodule_refs_hash=0A=20=20=20=20=20=3D=20=
make_hash_table=20(&hashtest_eq,=20DEFAULT_HASH_SIZE,=20Weak_None);=0A=20=
=0A+=20=20DEFSYM=20(Qmodule_out_of_memory,=20"module-out-of-memory");=0A=
+=20=20Fput=20(Qmodule_out_of_memory,=20Qerror_conditions,=0A+=09list2=20=
(Qmodule_out_of_memory,=20Qerror));=0A+=20=20Fput=20=
(Qmodule_out_of_memory,=20Qerror_message,=0A+=09build_unibyte_string=20=
("Module=20out=20of=20memory"));=0A+=0A+=20=20staticpro=20=
(&module_out_of_memory_symbol.v);=0A+=20=20module_out_of_memory_symbol.v=20=
=3D=20Qmodule_out_of_memory;=0A+=0A+=20=20staticpro=20=
(&module_out_of_memory_data.v);=0A+=20=20module_out_of_memory_data.v=20=3D=
=20Qnil;=0A+=0A=20=20=20DEFSYM=20(Qmodule_load_failed,=20=
"module-load-failed");=0A=20=20=20Fput=20(Qmodule_load_failed,=20=
Qerror_conditions,=0A=20=09list=20(Qmodule_load_failed,=20Qerror));=0A--=20=
=0A2.39.5=20(Apple=20Git-154)=0A=0A=

--Apple-Mail=_19C77EA4-DF56-4F6A-838F-A39D1668C8F8
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii




--Apple-Mail=_19C77EA4-DF56-4F6A-838F-A39D1668C8F8--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#65796; Package emacs. Full text available.

Message received at 65796 <at> debbugs.gnu.org:


Received: (at 65796) by debbugs.gnu.org; 29 Jan 2025 17:53:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 29 12:53:02 2025
Received: from localhost ([127.0.0.1]:42905 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tdCFK-00027M-5S
	for submit <at> debbugs.gnu.org; Wed, 29 Jan 2025 12:53:02 -0500
Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]:49259)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <chenxinyang99@HIDDEN>)
 id 1tdCFH-00026m-Qe
 for 65796 <at> debbugs.gnu.org; Wed, 29 Jan 2025 12:53:01 -0500
Received: by mail-lf1-x130.google.com with SMTP id
 2adb3069b0e04-543e47e93a3so1422468e87.2
 for <65796 <at> debbugs.gnu.org>; Wed, 29 Jan 2025 09:52:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1738173173; x=1738777973; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=wio1PX/4UBRIhg4xhhhaVZooTECCyYQVXFTW8vAkCtM=;
 b=TftjXQ0LYWH0pdvVsdi55orFTxia4Vdmow7Vfskwthc7L1Veme6WrRN70jOg1ZKGn0
 jd8PR/IOSB2vCHzunWXol+HUBPnpRMkcy0jE70En9Hdih+hA4ZNQ4K5F2XxwC0upSTCK
 pzybgqdflKgeOGiO2tv5mnDKUhpyjR97EzsJaiNSB4cHu5CCsQ5mwrsW+IhOaX7kO+dc
 aM3PbslZKqXL1mLqvgZXjOc7Opj5a6yRUJedoPvl2PkYz2LCXGpAkLiNO3ZW3B+V2VZz
 8Ku/1+fnH2UfsJd9toMPJEwIEPj72ekh5CohaISLU415t2AWMMIwOBokTVi6U6w9psz3
 JJjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1738173173; x=1738777973;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=wio1PX/4UBRIhg4xhhhaVZooTECCyYQVXFTW8vAkCtM=;
 b=IoxfGI7lYWWH7K41pr1xheWMyPtT/UPUC3QtUDgqr2dPbrOnFux2SxexuGoRVPydpI
 tzWtvH0ZxvqaBBgxV0YO/T5SHYGAQPML1KztkRebnadvDlHTuIc010sjjKwASlqqTr6G
 wAVQ8qWAh68UITVAGK5xVapcWCHCsv+azILdjasyTceFpNUtPlgvDijIDTouM7C2zeve
 G9MHi1QXD45RJXL+fWa+r/JiUTmMQq3GhU9syrePrOfi41GTMEWzC73PcMrv0+AHzFMN
 N1eWZVqnD/Pmot024HznldSEOWlBNTEYOR3pTE8JuctOiU17Ey2WlWX7yB/C5zbtt9Is
 ZgIw==
X-Forwarded-Encrypted: i=1;
 AJvYcCVsSZof5NINHQc+KQITDoCX6U96465KZ3/SERMONL1BCFOx4jZ8hW14leK8POXpfwbIQ0PyuQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyUVDWCByuqMclj8PRPd/CDjZpSFxGedXzBBEwdpG3d4h8B0N03
 8k7Qm8PPgY/7Jg2Spg901LlfHG3c4wLDhwEMeffYxhX0S4D9h/mWj/VOgLSrwqo0yFKm1SrT3JF
 /HghJdTdOEMX04aNfSr3sgXkbvMU=
X-Gm-Gg: ASbGncsHT8fGW//+vvdfChnb0NgBzRyLqaBxI4flVdGTZoIinQivZTsK4eSloWOu67/
 54zlkx4/b634zQNd06QVNshpxqLNCCSpZcZCl8VkkmA8nRHgPwtidybxNpZPDaj6Rw0Rwbjis
X-Google-Smtp-Source: AGHT+IE+UYT9U1n82iJCnMse1Tg1eua1LBrStPb6innbPspwrkfwNbq4DzV2EsNlBTlgX+NxmWOa8+CxpZSuPVkwBsw=
X-Received: by 2002:a05:6512:3d86:b0:543:bb21:4245 with SMTP id
 2adb3069b0e04-543e4c037a3mr1535160e87.28.1738173172925; Wed, 29 Jan 2025
 09:52:52 -0800 (PST)
MIME-Version: 1.0
References: <CANnQ9XZWvWTzcSvh+wVbTygOHtL4oYT9JZmBYK1SGSO9FCHaNQ@HIDDEN>
 <8334zq1mx6.fsf@HIDDEN>
 <CAP-RRPuCAGeyV+aZR5E338Wb5PMWOKqyT6Wt+nBT-yzPGgtP7g@HIDDEN>
In-Reply-To: <CAP-RRPuCAGeyV+aZR5E338Wb5PMWOKqyT6Wt+nBT-yzPGgtP7g@HIDDEN>
From: Xinyang Chen <chenxinyang99@HIDDEN>
Date: Wed, 29 Jan 2025 11:52:40 -0600
X-Gm-Features: AWEUYZlX_4c8vU5zzsna279xfrgoFg8cJix9_G_pzXG8POZT_eKjkoxB0FO_ENQ
Message-ID: <CANnQ9XagArsb_Fcj6kkBhnxQNNXqTxv=cU34hy33ynnoU7WojQ@HIDDEN>
Subject: Re: bug#65796: dynamic module non_local_exit_get overwrites exit
 signals
To: Philipp Stephani <phst@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000087d0b2062cdbfae2"
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 65796
Cc: Eli Zaretskii <eliz@HIDDEN>, Daniel Colascione <dancol@HIDDEN>,
 65796 <at> debbugs.gnu.org, p.stephani2@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--00000000000087d0b2062cdbfae2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This is still a problem.

Using a user buffer will require gc-protecting it and thus a major
overhaul, so I think it's not a good idea.

IMO what we should do is: if we fail to allocate, we discard the original
signal and replace it with an OOM signal (pointing to constants so
requiring no allocation). Perhaps we should make a new field
in emacs_funcall_exit for OOM, or we can just use emacs_funcall_exit_signal=
.

Alternatively, make a copy_emacs_value function that allows the user to
copy the signal out, returning NULL to let the caller know that an
allocation failure occurred.



On Thu, Sep 7, 2023 at 5:24=E2=80=AFAM Philipp Stephani <phst@HIDDEN> w=
rote:

> On Thu, 7 Sept 2023 at 09:07, Eli Zaretskii <eliz@HIDDEN> wrote:
> >
> > > From: Xinyang Chen <chenxinyang99@HIDDEN>
> > > Date: Wed, 6 Sep 2023 18:52:14 -0400
> > >
> > > Currently `module_non_local_exit_get` returns pointers to fields
> > > in emacs_env_private:
> > > ```
> > >   if (p->pending_non_local_exit !=3D emacs_funcall_exit_return)
> > >     {
> > >       *symbol =3D &p->non_local_exit_symbol;
> > >       *data =3D &p->non_local_exit_data;
> > >     }
> > > ```
> > > this means that if one tries to:
> > > ```
> > > funcall(...);
> > > non_local_exit_get(&s1, &d1);
> > > funcall(...);
> > > non_local_exit_get(&s2, &d2);
> > > non_local_exit_signal(s1, d1);
> > > ```
> > > you would signal the second error, instead of the first error (I
> expected
> > > this to happen).
> > > It seems to me that `module_non_local_exit_get` should
> > > `allocate_emacs_value` instead.
> >
> > Philipp, Daniel: any comments?
>
> Nice find!
> We can't use allocate_emacs_value here because non_local_exit_get has
> to work in OOM situations and can never fail. What we could do here is
> e.g.:
> - Document the current behavior, stating that the emacs_value objects
> returned from non_local_exit_get are ephemeral. I'm not a huge fan of
> this because it makes non_local_exit_get behave different from all
> other functions.
> - Provide an alternative non_local_exit_copy that copies the 2
> Lisp_Objects into an opaque buffer supplied by the user (plus a way to
> determine the buffer size). That way we shift the responsibility of
> dealing with allocation failures to the user.
> - Attempt to allocate a new emacs_value, fall back to the current
> behavior if that fails. I don't really like that option either because
> it doesn't solve the initial problem in all cases (so users still need
> to deal with it), but makes both the interface and the implementation
> more complex.
> - Crash if we can't allocate memory. That has been rejected in other case=
s.
>
> >
> > Btw, the non_local_exit_get function is currently not documented in
> > the ELisp manual; should it be?
>
> At least in Emacs 29 I see it documented ("Module Nonlocal" node).
>
>
> --
> Google Germany GmbH
> Erika-Mann-Stra=C3=9Fe 33
> 80636 M=C3=BCnchen
>
> Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
>
> Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise
> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes
> weiter, l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Si=
e mich
> bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.
>
> This e-mail is confidential. If you received this communication by
> mistake, please don=E2=80=99t forward it to anyone else, please erase all
> copies and attachments, and please let me know that it has gone to the
> wrong person.
>

--00000000000087d0b2062cdbfae2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">This is still a problem.</div><div dir=3D=
"ltr"><br></div><div>Using a user buffer will require gc-protecting it and =
thus a major overhaul, so I think it&#39;s=C2=A0not a good idea.</div><div>=
<br></div><div>IMO what we should do is: if we fail to allocate, we discard=
 the original signal and replace it with an OOM signal (pointing to constan=
ts so requiring no allocation). Perhaps we should make a new field in=C2=A0=
emacs_funcall_exit for OOM, or we can just use emacs_funcall_exit_signal.</=
div><div><br></div><div>Alternatively, make a copy_emacs_value function tha=
t allows the user to copy the signal out, returning NULL to let the caller =
know that an allocation failure occurred.</div><div><br></div><div><br></di=
v><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Thu, Sep 7, 2023 at 5:24=E2=80=AFAM Philipp Stephani &=
lt;<a href=3D"mailto:phst@HIDDEN">phst@HIDDEN</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 7 Sept 2023 at=
 09:07, Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank"=
>eliz@HIDDEN</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; From: Xinyang Chen &lt;<a href=3D"mailto:chenxinyang99@HIDDEN"=
 target=3D"_blank">chenxinyang99@HIDDEN</a>&gt;<br>
&gt; &gt; Date: Wed, 6 Sep 2023 18:52:14 -0400<br>
&gt; &gt;<br>
&gt; &gt; Currently `module_non_local_exit_get` returns pointers to fields<=
br>
&gt; &gt; in emacs_env_private:<br>
&gt; &gt; ```<br>
&gt; &gt;=C2=A0 =C2=A0if (p-&gt;pending_non_local_exit !=3D emacs_funcall_e=
xit_return)<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0{<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0*symbol =3D &amp;p-&gt;non_local_exit_s=
ymbol;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0*data =3D &amp;p-&gt;non_local_exit_dat=
a;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt; &gt; ```<br>
&gt; &gt; this means that if one tries to:<br>
&gt; &gt; ```<br>
&gt; &gt; funcall(...);<br>
&gt; &gt; non_local_exit_get(&amp;s1, &amp;d1);<br>
&gt; &gt; funcall(...);<br>
&gt; &gt; non_local_exit_get(&amp;s2, &amp;d2);<br>
&gt; &gt; non_local_exit_signal(s1, d1);<br>
&gt; &gt; ```<br>
&gt; &gt; you would signal the second error, instead of the first error (I =
expected<br>
&gt; &gt; this to happen).<br>
&gt; &gt; It seems to me that `module_non_local_exit_get` should<br>
&gt; &gt; `allocate_emacs_value` instead.<br>
&gt;<br>
&gt; Philipp, Daniel: any comments?<br>
<br>
Nice find!<br>
We can&#39;t use allocate_emacs_value here because non_local_exit_get has<b=
r>
to work in OOM situations and can never fail. What we could do here is<br>
e.g.:<br>
- Document the current behavior, stating that the emacs_value objects<br>
returned from non_local_exit_get are ephemeral. I&#39;m not a huge fan of<b=
r>
this because it makes non_local_exit_get behave different from all<br>
other functions.<br>
- Provide an alternative non_local_exit_copy that copies the 2<br>
Lisp_Objects into an opaque buffer supplied by the user (plus a way to<br>
determine the buffer size). That way we shift the responsibility of<br>
dealing with allocation failures to the user.<br>
- Attempt to allocate a new emacs_value, fall back to the current<br>
behavior if that fails. I don&#39;t really like that option either because<=
br>
it doesn&#39;t solve the initial problem in all cases (so users still need<=
br>
to deal with it), but makes both the interface and the implementation<br>
more complex.<br>
- Crash if we can&#39;t allocate memory. That has been rejected in other ca=
ses.<br>
<br>
&gt;<br>
&gt; Btw, the non_local_exit_get function is currently not documented in<br=
>
&gt; the ELisp manual; should it be?<br>
<br>
At least in Emacs 29 I see it documented (&quot;Module Nonlocal&quot; node)=
.<br>
<br>
<br>
--<br>
Google Germany GmbH<br>
Erika-Mann-Stra=C3=9Fe 33<br>
80636 M=C3=BCnchen<br>
<br>
Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian<br>
Registergericht und -nummer: Hamburg, HRB 86891<br>
Sitz der Gesellschaft: Hamburg<br>
<br>
Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise<br>
erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes<br>
weiter, l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie =
mich<br>
bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.<br>
<br>
This e-mail is confidential. If you received this communication by<br>
mistake, please don=E2=80=99t forward it to anyone else, please erase all<b=
r>
copies and attachments, and please let me know that it has gone to the<br>
wrong person.<br>
</blockquote></div></div>

--00000000000087d0b2062cdbfae2--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#65796; Package emacs. Full text available.

Message received at 65796 <at> debbugs.gnu.org:


Received: (at 65796) by debbugs.gnu.org; 7 Sep 2023 10:55:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 07 06:55:36 2023
Received: from localhost ([127.0.0.1]:38733 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qeCff-0006LZ-Iy
	for submit <at> debbugs.gnu.org; Thu, 07 Sep 2023 06:55:35 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:52582)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qeCfa-0006LJ-OP
 for 65796 <at> debbugs.gnu.org; Thu, 07 Sep 2023 06:55:34 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1qeCfT-00061O-3z; Thu, 07 Sep 2023 06:55:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=w05iH/8akOLHstJpHJstWmKEG9B7AXKQAJWYAubEtP8=; b=F/WBy237w0RX
 s5wOyjB8R0apQIxJgRZq89ZUZl988Zd8qhwcnguei/RFumqkayCH2Me5UbNs+yQCmKem180soZBbI
 zuDlXdfE0OD8rsIl0JByi/1HQQk4W+mHaMdDdH1v4y6AnsLHkRMH4QclBIj6PdVAxx/ZPJ31y0ICg
 Wu+dh4MSzhEgXdT7NlEQl/709j8yLZvtMFt6eFDMRr+1AM8E0x5+Xh/VNej39O1d9hxpXtnn+fmP9
 LM3nrEMfwT9JD2VGpVlldfHEg5GIE4dXa1MmgPP5wUfDODqyycetgzjPxHSlj+s8lXWi8oBwv06oL
 lcl9mXrGpLcI+AQQ65nWpw==;
Date: Thu, 07 Sep 2023 13:55:09 +0300
Message-Id: <83h6o6z20i.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Philipp Stephani <phst@HIDDEN>
In-Reply-To: <CAP-RRPuCAGeyV+aZR5E338Wb5PMWOKqyT6Wt+nBT-yzPGgtP7g@HIDDEN>
 (message from Philipp Stephani on Thu, 7 Sep 2023 12:24:03 +0200)
Subject: Re: bug#65796: dynamic module non_local_exit_get overwrites exit
 signals
References: <CANnQ9XZWvWTzcSvh+wVbTygOHtL4oYT9JZmBYK1SGSO9FCHaNQ@HIDDEN>
 <8334zq1mx6.fsf@HIDDEN>
 <CAP-RRPuCAGeyV+aZR5E338Wb5PMWOKqyT6Wt+nBT-yzPGgtP7g@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 65796
Cc: chenxinyang99@HIDDEN, p.stephani2@HIDDEN, dancol@HIDDEN,
 65796 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Philipp Stephani <phst@HIDDEN>
> Date: Thu, 7 Sep 2023 12:24:03 +0200
> Cc: Xinyang Chen <chenxinyang99@HIDDEN>, Daniel Colascione <dancol@HIDDEN>, 65796 <at> debbugs.gnu.org, 
> 	p.stephani2@HIDDEN
> 
> Nice find!
> We can't use allocate_emacs_value here because non_local_exit_get has
> to work in OOM situations and can never fail. What we could do here is
> e.g.:
> - Document the current behavior, stating that the emacs_value objects
> returned from non_local_exit_get are ephemeral. I'm not a huge fan of
> this because it makes non_local_exit_get behave different from all
> other functions.
> - Provide an alternative non_local_exit_copy that copies the 2
> Lisp_Objects into an opaque buffer supplied by the user (plus a way to
> determine the buffer size). That way we shift the responsibility of
> dealing with allocation failures to the user.
> - Attempt to allocate a new emacs_value, fall back to the current
> behavior if that fails. I don't really like that option either because
> it doesn't solve the initial problem in all cases (so users still need
> to deal with it), but makes both the interface and the implementation
> more complex.
> - Crash if we can't allocate memory. That has been rejected in other cases.

I guess just one alternative is acceptable?

> > Btw, the non_local_exit_get function is currently not documented in
> > the ELisp manual; should it be?
> 
> At least in Emacs 29 I see it documented ("Module Nonlocal" node).

I need new glasses.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#65796; Package emacs. Full text available.

Message received at 65796 <at> debbugs.gnu.org:


Received: (at 65796) by debbugs.gnu.org; 7 Sep 2023 10:24:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 07 06:24:30 2023
Received: from localhost ([127.0.0.1]:38698 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qeCBa-0005Np-1u
	for submit <at> debbugs.gnu.org; Thu, 07 Sep 2023 06:24:30 -0400
Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]:36089)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <phst@HIDDEN>) id 1qeCBY-0005Nd-Lw
 for 65796 <at> debbugs.gnu.org; Thu, 07 Sep 2023 06:24:29 -0400
Received: by mail-ed1-x534.google.com with SMTP id
 4fb4d7f45d1cf-51e24210395so11114a12.0
 for <65796 <at> debbugs.gnu.org>; Thu, 07 Sep 2023 03:24:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=google.com; s=20221208; t=1694082261; x=1694687061; darn=debbugs.gnu.org;
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:from:to:cc:subject:date
 :message-id:reply-to;
 bh=QMqBwGul96xihfaV6H0gOMf/kK0hd+bVLZwS3P7t9LY=;
 b=vD77yKWwMbY+OAE82PhMc1a+A/FqLQ3pB71hWn8RjHMldSq5kz5vJTRy2WFvrUIlye
 pm3j+EUnzVho660iSh5gSXqDSIeDTjXa6vQq+tB7gB/xmqtzcU0ZR1YEqpRvp5b2p8v+
 80a0g0yc8ZPL2cvRL4aw5fAshXm/GIzFi2jIPy21s7qjL4mQACAv4CKfVTzpY2gpWJ9j
 2gai2pS3Di6kmRgq9QBL4sbI3+EJWxCyCQff0K+k9OZEYdyrzlL1sW8tc7aTewqX0eHl
 71gV5ubRD1PXqZryBd9fILA2kCDGtvTa/alhKS+iNSFisrvj+CC+dtBy7FQct7LBEq8W
 mIiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1694082261; x=1694687061;
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=QMqBwGul96xihfaV6H0gOMf/kK0hd+bVLZwS3P7t9LY=;
 b=FQUMZrcffRTemRACQ0TIm8rC6J+fLmWSjM9G8Q+E7ahqHz3uxwv5D+TMg5WP4l49aW
 LmPm0sAPjlCOVP0IwjP5JLG14a7unmMdCT16BTUr2brZpe7Kma+v+nacQyZgUxAxke8g
 LFBKOtwhj5REANU5KcuKs56jmhh1PkjGt9s2dfHdjbZVHC2ug4AH5TZeqrpF7ZEw7GxK
 BRatCU6P/jvsm3LvrPP5QvIYv8HJ/Ah5PGBdBodWTessL4jC0IrcPc49ror3jfMfsol1
 ZFzbRkpn3jPW9hwUFJlvIPyIDripMkU+itZG4SCccn0kzVPKnPL3vH0O3KzO3R2I74PD
 3T4A==
X-Gm-Message-State: AOJu0Yy5dDwU6gcPgmb14Qo/5p49EBHr+xipxuRrmHGNFkDXyZxpkM7q
 INp27BDAuacawOD5ZuseHXycWZ4hoawZTPxyrc7tLg==
X-Google-Smtp-Source: AGHT+IFRbVWKm09CmY2Tqjzhk751oh+VYO5On7AaytSHvVaEXuE/ETRAOSQR2F4Lhn8TM/pjUKJ8gV9tu89/gkPkdwU=
X-Received: by 2002:a50:d089:0:b0:522:cc9c:f5a4 with SMTP id
 v9-20020a50d089000000b00522cc9cf5a4mr99251edd.4.1694082260577; Thu, 07 Sep
 2023 03:24:20 -0700 (PDT)
MIME-Version: 1.0
References: <CANnQ9XZWvWTzcSvh+wVbTygOHtL4oYT9JZmBYK1SGSO9FCHaNQ@HIDDEN>
 <8334zq1mx6.fsf@HIDDEN>
In-Reply-To: <8334zq1mx6.fsf@HIDDEN>
From: Philipp Stephani <phst@HIDDEN>
Date: Thu, 7 Sep 2023 12:24:03 +0200
Message-ID: <CAP-RRPuCAGeyV+aZR5E338Wb5PMWOKqyT6Wt+nBT-yzPGgtP7g@HIDDEN>
Subject: Re: bug#65796: dynamic module non_local_exit_get overwrites exit
 signals
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -8.0 (--------)
X-Debbugs-Envelope-To: 65796
Cc: Xinyang Chen <chenxinyang99@HIDDEN>, p.stephani2@HIDDEN,
 Daniel Colascione <dancol@HIDDEN>, 65796 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -9.0 (---------)

On Thu, 7 Sept 2023 at 09:07, Eli Zaretskii <eliz@HIDDEN> wrote:
>
> > From: Xinyang Chen <chenxinyang99@HIDDEN>
> > Date: Wed, 6 Sep 2023 18:52:14 -0400
> >
> > Currently `module_non_local_exit_get` returns pointers to fields
> > in emacs_env_private:
> > ```
> >   if (p->pending_non_local_exit !=3D emacs_funcall_exit_return)
> >     {
> >       *symbol =3D &p->non_local_exit_symbol;
> >       *data =3D &p->non_local_exit_data;
> >     }
> > ```
> > this means that if one tries to:
> > ```
> > funcall(...);
> > non_local_exit_get(&s1, &d1);
> > funcall(...);
> > non_local_exit_get(&s2, &d2);
> > non_local_exit_signal(s1, d1);
> > ```
> > you would signal the second error, instead of the first error (I expect=
ed
> > this to happen).
> > It seems to me that `module_non_local_exit_get` should
> > `allocate_emacs_value` instead.
>
> Philipp, Daniel: any comments?

Nice find!
We can't use allocate_emacs_value here because non_local_exit_get has
to work in OOM situations and can never fail. What we could do here is
e.g.:
- Document the current behavior, stating that the emacs_value objects
returned from non_local_exit_get are ephemeral. I'm not a huge fan of
this because it makes non_local_exit_get behave different from all
other functions.
- Provide an alternative non_local_exit_copy that copies the 2
Lisp_Objects into an opaque buffer supplied by the user (plus a way to
determine the buffer size). That way we shift the responsibility of
dealing with allocation failures to the user.
- Attempt to allocate a new emacs_value, fall back to the current
behavior if that fails. I don't really like that option either because
it doesn't solve the initial problem in all cases (so users still need
to deal with it), but makes both the interface and the implementation
more complex.
- Crash if we can't allocate memory. That has been rejected in other cases.

>
> Btw, the non_local_exit_get function is currently not documented in
> the ELisp manual; should it be?

At least in Emacs 29 I see it documented ("Module Nonlocal" node).


--
Google Germany GmbH
Erika-Mann-Stra=C3=9Fe 33
80636 M=C3=BCnchen

Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise
erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes
weiter, l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie =
mich
bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

This e-mail is confidential. If you received this communication by
mistake, please don=E2=80=99t forward it to anyone else, please erase all
copies and attachments, and please let me know that it has gone to the
wrong person.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#65796; Package emacs. Full text available.

Message received at 65796 <at> debbugs.gnu.org:


Received: (at 65796) by debbugs.gnu.org; 7 Sep 2023 07:07:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 07 03:07:55 2023
Received: from localhost ([127.0.0.1]:38410 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qe97K-00063m-TU
	for submit <at> debbugs.gnu.org; Thu, 07 Sep 2023 03:07:55 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:57282)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qe97J-00063Z-IY
 for 65796 <at> debbugs.gnu.org; Thu, 07 Sep 2023 03:07:54 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1qe97C-0007EL-5X; Thu, 07 Sep 2023 03:07:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=BK3rW+eT2Jcc9r6id1iYqQZrsy1nKvCwc5oabv7D6Mk=; b=i5IR9+5q4esT
 uNggmLyKlRBHB9n2SoCIwPEU4ZH97sRaJekh2m2LC09tC4x7AFNsBaAfRpjAf+YR0mtoO6m53ABYM
 KCK1VkpTbGsZsZtR2WymQX7vXZ8CYc24mB8+oJ7hqOyMQAkGRvbiPF9E5gBpyS+5B8I85bcKJo/v+
 otQl9GTmh9RX3rml/pDJE+88LulAgS8uhu2eDvhLZZgF5ySRAq0RrTyKoiRTDUnaTx7QcIGDTgHTG
 1vEucXlRGIJpl6BDKcCtlBUJpTUP7WMccpqTURtClwx56sYl61q3octcB4r6kVX4f07AgO16YBVTl
 140SKbiFvq6mLvdPvBHztw==;
Date: Thu, 07 Sep 2023 10:07:33 +0300
Message-Id: <8334zq1mx6.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Xinyang Chen <chenxinyang99@HIDDEN>, Philipp Stephani <phst@HIDDEN>,
 Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <CANnQ9XZWvWTzcSvh+wVbTygOHtL4oYT9JZmBYK1SGSO9FCHaNQ@HIDDEN>
 (message from Xinyang Chen on Wed, 6 Sep 2023 18:52:14 -0400)
Subject: Re: bug#65796: dynamic module non_local_exit_get overwrites exit
 signals
References: <CANnQ9XZWvWTzcSvh+wVbTygOHtL4oYT9JZmBYK1SGSO9FCHaNQ@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 65796
Cc: 65796 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Xinyang Chen <chenxinyang99@HIDDEN>
> Date: Wed, 6 Sep 2023 18:52:14 -0400
> 
> Currently `module_non_local_exit_get` returns pointers to fields
> in emacs_env_private:
> ```
>   if (p->pending_non_local_exit != emacs_funcall_exit_return)
>     {
>       *symbol = &p->non_local_exit_symbol;
>       *data = &p->non_local_exit_data;
>     }
> ```
> this means that if one tries to:
> ```
> funcall(...);
> non_local_exit_get(&s1, &d1);
> funcall(...);
> non_local_exit_get(&s2, &d2);
> non_local_exit_signal(s1, d1);
> ```
> you would signal the second error, instead of the first error (I expected
> this to happen).
> It seems to me that `module_non_local_exit_get` should
> `allocate_emacs_value` instead.

Philipp, Daniel: any comments?

Btw, the non_local_exit_get function is currently not documented in
the ELisp manual; should it be?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#65796; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 7 Sep 2023 04:58:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 07 00:58:42 2023
Received: from localhost ([127.0.0.1]:38293 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qe76G-0002dV-Mf
	for submit <at> debbugs.gnu.org; Thu, 07 Sep 2023 00:58:42 -0400
Received: from lists.gnu.org ([2001:470:142::17]:38400)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <chenxinyang99@HIDDEN>) id 1qe1O0-0001w6-Hb
 for submit <at> debbugs.gnu.org; Wed, 06 Sep 2023 18:52:51 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <chenxinyang99@HIDDEN>)
 id 1qe1Nt-0002y7-Qz
 for bug-gnu-emacs@HIDDEN; Wed, 06 Sep 2023 18:52:29 -0400
Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <chenxinyang99@HIDDEN>)
 id 1qe1Nr-0004dq-Jn
 for bug-gnu-emacs@HIDDEN; Wed, 06 Sep 2023 18:52:29 -0400
Received: by mail-lf1-x135.google.com with SMTP id
 2adb3069b0e04-5008faf4456so476971e87.3
 for <bug-gnu-emacs@HIDDEN>; Wed, 06 Sep 2023 15:52:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1694040745; x=1694645545; darn=gnu.org;
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=UEGDdO1L0h3GqkNVTA7xe3xYmYuPQ6k7cPE2FglE94g=;
 b=RplZt4rnN+ohxxmfyNWqX75hEUk8Grlu3xwY56fKKDc4LX1Z06mT4PtciMq8BTPN1t
 ezi11DqnywJ2H7ReA7FXx3Psq/E2nfkPJc8RbUXzv4n45eGF653tA0FOYqked9cuI3PV
 XUR57pfg8VnJZArf65O52bWqz3vu9JOY+GTPucuu7TEYDmpeUa/Oa+F/2w4VpDsC89p6
 c4wQ7mNcnTk4eSvTkAV98+VgfTTlMFJpMksDBL4t57ykteQ4ubno2eNysJgN7uLry3FW
 TKhBgglM/D0wEDOqw8Y3R08k+sGMzIUuRXx54Q1Cc4vq9wjqvnrmnRYpJY0yTt09y1G9
 2DyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1694040745; x=1694645545;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=UEGDdO1L0h3GqkNVTA7xe3xYmYuPQ6k7cPE2FglE94g=;
 b=dqp6+hRAixZU55YW4jJibUbVu6KP8bUoJUISR0Wr8/NX4GUcw41dV3+r/tRWR3KRHa
 p01tMb/jnFMjyoY8zNJQODouP5ZXfSzq7bC+8Fj6J1hTazoHF8ozrmYEdQlKulZX+1ZX
 NgQIS+gkayRtw/khUi/4f3WfBer/ERPpArKD0HM7klHrlqasIhTIpk8AP0XZSuVzW211
 8dZctM9sPLS6dZAa3c95b9TdDQxPouSCdis1dLnyHV4SjUOM8IIVJ4Dn5oqCl3W6gOMc
 x0PhsYEvUecivy90LcriLbHO22ceHXNR3omnkbqXYgVwW/SRtKIpYSrAtIPcL3369ORT
 09zA==
X-Gm-Message-State: AOJu0Yw2y+3DTdIyF67tKTPL0rT/CXc1/VbmhXTNtS/EOW2elfKvuAkj
 FasoUguBhGmMXd77qeILoSSplP8gtURXOKsBKXjBM7+o8QwldQ==
X-Google-Smtp-Source: AGHT+IHpVKT6FbIDG/m6WrLPr1fIKiHtxmlUV25GrILNDhJj1dpTcaP35he2zM78YxW4I7CcY7fvxBiNHbDzow0/okg=
X-Received: by 2002:ac2:4830:0:b0:500:bf33:3add with SMTP id
 16-20020ac24830000000b00500bf333addmr3195110lft.47.1694040744858; Wed, 06 Sep
 2023 15:52:24 -0700 (PDT)
MIME-Version: 1.0
From: Xinyang Chen <chenxinyang99@HIDDEN>
Date: Wed, 6 Sep 2023 18:52:14 -0400
Message-ID: <CANnQ9XZWvWTzcSvh+wVbTygOHtL4oYT9JZmBYK1SGSO9FCHaNQ@HIDDEN>
Subject: dynamic module non_local_exit_get overwrites exit signals
To: bug-gnu-emacs@HIDDEN
Content-Type: multipart/alternative; boundary="000000000000d51bc30604b89823"
Received-SPF: pass client-ip=2a00:1450:4864:20::135;
 envelope-from=chenxinyang99@HIDDEN; helo=mail-lf1-x135.google.com
X-Spam_score_int: -17
X-Spam_score: -1.8
X-Spam_bar: -
X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Currently `module_non_local_exit_get` returns pointers to
 fields in emacs_env_private: ``` if (p->pending_non_local_exit !=
 emacs_funcall_exit_return)
 { *symbol = &p->non_local_exit_symbol; *data = &p [...] 
 Content analysis details:   (1.2 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
 in digit (chenxinyang99[at]gmail.com)
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (chenxinyang99[at]gmail.com)
 0.0 T_SPF_HELO_TEMPERROR   SPF: test of HELO record failed (temperror)
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 0.0 HTML_MESSAGE           BODY: HTML included in message
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Thu, 07 Sep 2023 00:58:39 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

--000000000000d51bc30604b89823
Content-Type: text/plain; charset="UTF-8"

Currently `module_non_local_exit_get` returns pointers to fields
in emacs_env_private:
```
  if (p->pending_non_local_exit != emacs_funcall_exit_return)
    {
      *symbol = &p->non_local_exit_symbol;
      *data = &p->non_local_exit_data;
    }
```
this means that if one tries to:
```
funcall(...);
non_local_exit_get(&s1, &d1);
funcall(...);
non_local_exit_get(&s2, &d2);
non_local_exit_signal(s1, d1);
```
you would signal the second error, instead of the first error (I expected
this to happen).
It seems to me that `module_non_local_exit_get` should
`allocate_emacs_value` instead.

-Alan

--000000000000d51bc30604b89823
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Currently=C2=A0`module_non_local_exit_get` returns=C2=A0po=
inters to fields in=C2=A0emacs_env_private:<div>```</div><div>=C2=A0 if (p-=
&gt;pending_non_local_exit !=3D emacs_funcall_exit_return)<br>=C2=A0 =C2=A0=
 {<br>=C2=A0 =C2=A0 =C2=A0 *symbol =3D &amp;p-&gt;non_local_exit_symbol;<br=
>=C2=A0 =C2=A0 =C2=A0 *data =3D &amp;p-&gt;non_local_exit_data;<br>=C2=A0 =
=C2=A0 }<br></div><div>```</div><div>this means that if one tries to:<div>`=
``<br><div>funcall(...);</div><div>non_local_exit_get(&amp;s1, &amp;d1);<br=
></div><div><div>funcall(...);</div><div>non_local_exit_get(&amp;s2, &amp;d=
2);</div></div><div>non_local_exit_signal(s1, d1);</div><div>```</div></div=
><div>you would=C2=A0signal the second error, instead of the first error (I=
 expected this to happen).</div></div><div>It seems to me that `module_non_=
local_exit_get` should `allocate_emacs_value` instead.</div><div><br></div>=
<div>-Alan</div></div>

--000000000000d51bc30604b89823--




Acknowledgement sent to Xinyang Chen <chenxinyang99@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#65796; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Tue, 25 Feb 2025 23:30:02 UTC

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