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 12:08:42 +0000 Message-ID: <87ttaz98q1.fsf@protonmail.com> References: <86seqmm9dq.fsf@gnu.org> <87frml9cy4.fsf@protonmail.com> <875xng9g48.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="18562"; 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 Thu Dec 19 13:31:34 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 1tOFgj-0004eG-Tu for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Dec 2024 13:31:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tOFgD-0000Z2-NT; Thu, 19 Dec 2024 07:31:02 -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 1tOFKr-0005PT-2g for emacs-devel@gnu.org; Thu, 19 Dec 2024 07:08:57 -0500 Original-Received: from mail-10628.protonmail.ch ([79.135.106.28]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tOFKn-0007Yj-5n; Thu, 19 Dec 2024 07:08:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1734610127; x=1734869327; bh=XQT79c5xtaHRk0/PYGoynHXB2ir6/j390zHV1ikmId0=; 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=pgprPIukzJDROCEiVFrlfaX/sLpBomd6X5wphgwBpU9cFMFz/uDh6LQWVEKRbaPmS 5iB1UojPYhxC9lHiKrRWvDjPeWWWX5fOSCslQxN9htmX0aRXGL1Wnr/K5HdViz+KBB FBu+RNQXyLqvv0df1rJ4dKuvD6YtLAWUTlHB0lxpgUNvMP0K64PMtTlG9GVUd1jGdR EK6zC3Gro0uzrBlEyYsI3wqTUSf65vy5qIHARlpkVdVTJ3mYTE+vKc8OF+kOVd7ua3 t7uQQdZDKlepPZCLD9Gaia/avPXtnHeiW9uRHsH2+z/5o+a2bKacG+qFGJxjPBfvid sglx1wP2g/9mQ== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: feac05bdb9bdc3b835a2b90e967e4f93a41d03a1 Received-SPF: pass client-ip=79.135.106.28; envelope-from=pipcet@protonmail.com; helo=mail-10628.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_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=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 19 Dec 2024 07:30:44 -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:326734 Archived-At: "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). 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). Pip