Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.
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--
bug-gnu-emacs@HIDDEN:bug#65796; Package emacs.
Full text available.
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'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>> 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 <<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank"=
>eliz@HIDDEN</a>> wrote:<br>
><br>
> > From: Xinyang Chen <<a href=3D"mailto:chenxinyang99@HIDDEN"=
target=3D"_blank">chenxinyang99@HIDDEN</a>><br>
> > Date: Wed, 6 Sep 2023 18:52:14 -0400<br>
> ><br>
> > Currently `module_non_local_exit_get` returns pointers to fields<=
br>
> > in emacs_env_private:<br>
> > ```<br>
> >=C2=A0 =C2=A0if (p->pending_non_local_exit !=3D emacs_funcall_e=
xit_return)<br>
> >=C2=A0 =C2=A0 =C2=A0{<br>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0*symbol =3D &p->non_local_exit_s=
ymbol;<br>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0*data =3D &p->non_local_exit_dat=
a;<br>
> >=C2=A0 =C2=A0 =C2=A0}<br>
> > ```<br>
> > this means that if one tries to:<br>
> > ```<br>
> > funcall(...);<br>
> > non_local_exit_get(&s1, &d1);<br>
> > funcall(...);<br>
> > non_local_exit_get(&s2, &d2);<br>
> > non_local_exit_signal(s1, d1);<br>
> > ```<br>
> > you would signal the second error, instead of the first error (I =
expected<br>
> > this to happen).<br>
> > It seems to me that `module_non_local_exit_get` should<br>
> > `allocate_emacs_value` instead.<br>
><br>
> Philipp, Daniel: any comments?<br>
<br>
Nice find!<br>
We can'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'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't really like that option either because<=
br>
it doesn'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't allocate memory. That has been rejected in other ca=
ses.<br>
<br>
><br>
> Btw, the non_local_exit_get function is currently not documented in<br=
>
> the ELisp manual; should it be?<br>
<br>
At least in Emacs 29 I see it documented ("Module Nonlocal" 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--
bug-gnu-emacs@HIDDEN:bug#65796; Package emacs.
Full text available.
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.
bug-gnu-emacs@HIDDEN:bug#65796; Package emacs.
Full text available.
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.
bug-gnu-emacs@HIDDEN:bug#65796; Package emacs.
Full text available.
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?
bug-gnu-emacs@HIDDEN:bug#65796; Package emacs.
Full text available.
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-=
>pending_non_local_exit !=3D emacs_funcall_exit_return)<br>=C2=A0 =C2=A0=
{<br>=C2=A0 =C2=A0 =C2=A0 *symbol =3D &p->non_local_exit_symbol;<br=
>=C2=A0 =C2=A0 =C2=A0 *data =3D &p->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(&s1, &d1);<br=
></div><div><div>funcall(...);</div><div>non_local_exit_get(&s2, &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--
Xinyang Chen <chenxinyang99@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#65796; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.