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.