From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Merging scratch/no-purespace to remove unexec and purespace Date: Thu, 19 Dec 2024 12:55:01 -0500 Message-ID: References: <86seqmm9dq.fsf@gnu.org> <87frml9cy4.fsf@protonmail.com> <875xng9g48.fsf@protonmail.com> <87ttaz98q1.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9823"; 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: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 19 18:55:56 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 1tOKke-0002LC-KJ for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Dec 2024 18:55:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tOKjz-0004L2-Os; Thu, 19 Dec 2024 12:55:15 -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 1tOKjq-0004IP-L2 for emacs-devel@gnu.org; Thu, 19 Dec 2024 12:55:08 -0500 Original-Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tOKjo-0004dY-Cc; Thu, 19 Dec 2024 12:55:05 -0500 Original-Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5d7e3f1fdafso2053766a12.0; Thu, 19 Dec 2024 09:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734630902; x=1735235702; darn=gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=aBeTAgZ3C8Ul4DDfODyCUU5sx2w87N5Cm40rMMcuflg=; b=c4JLA20IgCnTnE3NBUw2fZ0zbla3h/OW+7M/xDs3/k/Y724WkMpxKN2sIC0QORkCVn 5x0vQBicHHSDF/ak/QIfto9LVSUGHBnkYMO5ZyLHCZ4RyPbgDEsBGx2QvodbT8NAPvvk l4IEy499baSsgeoLzlLJAqBNeE7TWmbU9bvHDWSs+ggD0cjM9cgfS2YVa5M8kRydmSQ/ Xl1uZ3Kow/PLC+DSeb+pkXmLzEoWTozCg09Sm+YqAQblKT61O6W23Y1GlRKgEESTdP9e uO/PgmgOGmTjvynHt4R9vmRnfR1RZ7nCc+tnccw3v3XMSU0bK/zm7pQ6tZGFl4p2GWBV Z0eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734630902; x=1735235702; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aBeTAgZ3C8Ul4DDfODyCUU5sx2w87N5Cm40rMMcuflg=; b=iM2rdHvmiCnjEGGY+koFYQDvAZS2p02dnUcFCttFCYoLzLXX+PicIkPMXnKxv0QfBr ZgwzM+pFaukf4Un+9jXo8A4uSQRgzN2Fp9Ely8myVcfxFMUTKS1tverK/4cID3DJhbpA +WGB/to6ktn+QFyiUjJ6XJMVOTLv93ObtyUb0sjAgBjv4SMxbMM9wywL39xCvaoZ5czq WIX2tDL8EVdf0dKq5HFWZV7MocOA/H7ZW9r2RhzOgkk+g+q+8yp6rhi9kdVfxM2kbAm/ 0tSMPDf3lIm+8Kve3kOiasLLYLswa3qVVgigSISEHnu2R4f3gZXIBHb3O3xfvI1t8gQ6 txfw== X-Forwarded-Encrypted: i=1; AJvYcCUDUN3ZE8s74+b5hVeThydRq4K10VhokxnQGgpXzREBWGQDNFfFIMB7DljKCFFSmTdQWdtnR7qLfqvJWSI=@gnu.org, AJvYcCUJdBO6Gv4gJ3vO6Y9VVJyOoYtHKLVbwYBXGNcSlgZvhjLrZK1DUYxPx6463rZUXcknV7V/@gnu.org X-Gm-Message-State: AOJu0YxWad+D3EJ08ThgK/6nQ4s5BkHbST6VjBgtCKnElVa5ucvp8SUk nt4EkPYriPGQ1VuT8wQaJyMCp82Uourd7vn12uQC5ofaVym9GCCFRoWrWYzZaiT9I8w5ywLO0yK sEK63g2D+0HPHz6KxcyieLRSuCwI= X-Gm-Gg: ASbGncs9bjZLs6bBgMaaHZH8B4aYQ3itXKcziXYleqvf2rDgW7XOlELyUB0kyg26Zqv nujz1RJbgcezKFYAGt2KAekF8eCxGDCzKjL0esA== X-Google-Smtp-Source: AGHT+IH3DRlYCLJ4Vi7GODqkV7VZ5pB5e3HfDXIQd8txyPIVUU9q5CcXP6XSHnaeMAmWgqr24l8F3SFDF+s4G551f8w= X-Received: by 2002:a05:6402:354b:b0:5d0:e826:f10a with SMTP id 4fb4d7f45d1cf-5d7ee3bacbemr5882465a12.6.1734630901684; Thu, 19 Dec 2024 09:55:01 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 19 Dec 2024 12:55:01 -0500 In-Reply-To: <87ttaz98q1.fsf@protonmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::536; envelope-from=stefankangas@gmail.com; helo=mail-ed1-x536.google.com 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:326757 Archived-At: 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'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?