From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Merging scratch/no-purespace to remove unexec and purespace Date: Thu, 19 Dec 2024 20:13:43 +0000 Message-ID: <87y10b77p7.fsf@protonmail.com> References: <87frml9cy4.fsf@protonmail.com> <875xng9g48.fsf@protonmail.com> <87ttaz98q1.fsf@protonmail.com> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29867"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrea Corallo , =?utf-8?Q?Gerd_M=C3=B6llmann?= , Eli Zaretskii , emacs-devel@gnu.org, monnier@iro.umontreal.ca To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 20 05:40:24 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tOUoJ-0007cQ-L8 for ged-emacs-devel@m.gmane-mx.org; Fri, 20 Dec 2024 05:40:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tOUnT-00078B-Qg; Thu, 19 Dec 2024 23:39:31 -0500 Original-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 ) id 1tOMuM-0004bd-Sh for emacs-devel@gnu.org; Thu, 19 Dec 2024 15:14:07 -0500 Original-Received: from mail-4316.protonmail.ch ([185.70.43.16]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tOMuH-000839-Hl for emacs-devel@gnu.org; Thu, 19 Dec 2024 15:14:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1734639225; x=1734898425; bh=3RXIwwCi/L1chkSLSPlEnZda5aJwmaEUb8BgZBDZ3BE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=taJEnYWHASJzisggFXO0MmM8A++4olXnp0og/kjuYhUQmlBy9UfJadFsyepdHxpvK RreQmg+Vhpfox0Flz+5oxCeGj22i9/WlSBERFNng89wDdU4EJ5B/27stdGjUcAdh20 AZzP+GdhcJ1JODRoqK39PcV711DIpoI7LyTOqgWTY10iHfBrv9eQgDDMMrwmoc6d+l EIrmEr199Szot6D7ECduuocbS0XDnKcA12eu8sBt/c+kgR976rPl397YWfxxWdTOAP RWmzZxyA73+va0zFtTQvOweuBGM8Au7SLOgGn2UDsN+fW928oRxT/sCjyU4MapBc3h Jzc80LYz6gPTA== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: eb165fe1afecb643ccf9ab5b76ac0af925f1d7af Received-SPF: pass client-ip=185.70.43.16; envelope-from=pipcet@protonmail.com; helo=mail-4316.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 19 Dec 2024 23:39:29 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326769 Archived-At: "Stefan Kangas" writes: > Pip Cet writes: > >> "Stefan Kangas" writes: >> >>> Pip Cet writes: >>> >>>> What I think we should do doesn't really matter, but it seems quite >>>> obvious to me that we should make the code on the master branch >>>> perform all three checks on all relocations, as the code on >>>> no-purespace does. >>> >>> Maybe. But won't we get those checks with no additional effort once we >>> merge no-purespace, >> >> Yes, we will. (And the forbidden symbol; even if the forbidden symbol >> doesn't cause trouble, which I think it will, it's simply very poor >> programming practice to do things that way, particularly since the >> crash may happen a long time after the compilation. But, again, what I >> think obviously doesn't matter here. I'll just remember that >> --enable-checking causes false positive crashes and shouldn't be used). > > I don't think the existence of one symbol that will crash Emacs in some > situations means that --enable-checking should be completely avoided. > It's still quite useful, and we're fine as long as we avoid using that > one symbol, right? > > OTOH and IMHO, it would be preferable if that symbol could not crash > Emacs. Can we come up with a good way to fix that, while preserving the > check that Andrea wants to keep? That sounds like a good thing to focus on, yes. We need to have a value in a vector that we Fread that is distinguishable from all other values. One cheap way of doing that is to make the structure circular, and use references to the object being read as a placeholder value. So instead of having "[a b lambda-fixup c]" in the blob, we'd have "#1=3D[a b #1# c]" Note that that makes element 2 of the vector EQ to the vector being read, which only comes into existence during reading, so there's no way to create such a reference in any other way. We could also make this more explicit by using a more complex expression involving #1# instead of #1# directly. For example, "#1=3D[a b (unresolved-lambda-fixup #1#) c]" One side effect is that we need to make sure read-circle is t before reading the string (which is, IIUC, already produced with print-circle bound to t, so reading it with read-circle seems like the correct thing to do). For example, right now this code doesn't work: (let ((print-circle t) (read-circle nil)) (message "%S" (funcall (native-compile (lambda () #1=3D[#1#]))))) (read, of course, with read-circle bound to t) but this does: (let ((print-circle t) (read-circle nil)) (message "%S" (funcall (lambda () #1=3D[#1#])))) So this seems like a cheap drive-by fix. A more complicated approach would be to add a special read syntax (if there isn't one that I missed) producing references to objects defined outside of the read string: in essence, we'd call Fread in a special way that makes #s(magic-cookie x) evaluate to be eq to something passed in as a "magic cookie". This might be generally useful and avoids the problems of circular data structures. But I'll try to come up with a patch doing the simple #1# thing first. >> That's a problem, because if we run into problems there, we'll have no >> way of knowing whether the problem was present on the pre-merge master >> (where we didn't check) or not. But, again, as it's specific to >> --enable-checking, we can simply stop using that. >> >>> and if so, can't it wait until then? >> >> Of course, but changing two things at a time makes debugging harder. >> (And IIUC, we won't rename the symbol on master until we merge, so >> that's three changes which can cause trouble with the nativecomp code, >> all introduced at the same time). > > I still don't think I understand your argument here, sorry. > > The scratch/no-purespace branch contains several different changes, all > of which have had to pass through review, testing and verification. > Why is it particularly important to "backport" this change to master, in > advance of the merge, but not any of the other changes on that branch? > What am I missing? On reflection, it was I who was missing something, that no-purespace already has moved from "the minimum set of changes necessary for getting rid of purespace and unexec" to "a coherent set of changes including purespace and unexec removal and quite a few other things". I think that's a good change to have happened, it just took me a while to catch up with it. So no continued objections there. Pip