From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.devel Subject: Re: Finalizing 'inhibit-automatic-native-compilation' Date: Mon, 20 Feb 2023 18:24:23 +0100 Message-ID: References: <20230218.061335.1468428093197134401.tats%nobody@tats.iris.ne.jp> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PldgKDWZWy5HYt8/" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13295"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 20 18:25:31 2023 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 1pU9us-0003FE-HF for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Feb 2023 18:25:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pU9u0-0004tH-W4; Mon, 20 Feb 2023 12:24:37 -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 1pU9tx-0004t0-Mx for emacs-devel@gnu.org; Mon, 20 Feb 2023 12:24:35 -0500 Original-Received: from mail.tuxteam.de ([5.199.139.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU9tv-0006W3-Ix for emacs-devel@gnu.org; Mon, 20 Feb 2023 12:24:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=From:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fvWV95TCuZPZk3UOgetSP1BHoj/8T15p5lpICsn9iYA=; b=nMNUTs4Z+b4V67i+P4SRwWEbqq KMRMNqBZkQVBb0Kb9PazvzdCurgvVg1yvBPaKVMmFWMvJ4pKc0NeRzpwmpKC+xa3zfDALoL1rPHEY lFhg9V+E1mZvdWfe470tUbjPR1dyY5aDZbgm4Kwf5mbzcW1ql5BimhPdTEkZjXzmDyUQwC1wnoSj4 h5eh9E1sVcuXN1pPIt7/Rvn8Hl4t0Jlgo11lA31Qc+w2dtlKkAdc7NXSkMroM+VKKWLyJzCM2TV7Z VS2f0DkNbRJdLwJFby3gKNj+SeL201+CqOiMY01xEq40iLHErFInaa0rQlmZ1lecLdit0xQFUpMIj oVDCyJCw==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.94.2) (envelope-from ) id 1pU9tn-0007Zl-57 for emacs-devel@gnu.org; Mon, 20 Feb 2023 18:24:23 +0100 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de 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, 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:303618 Archived-At: --PldgKDWZWy5HYt8/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 20, 2023 at 04:07:59PM +0000, Andrea Corallo wrote: > Stefan Monnier writes: >=20 > >>> `make-temp-name` uses `O_EXCL | O_CREAT` so as to close the race [...] > > *BUT* `O_EXCL | O_CREAT` will fail if the file already exists. Which is > > why `make-temp-file` needs `make-temp-name` to generate new names until > > we find one that really doesn't exist (not just at the time > > `make-temp-name` is called but the fraction of a millisecond later when > > we do try to create it). >=20 > We can't use this loop, we tipically pass a filename to be used to > libgccjit and we have no control after (also see my last comment). I think the idea is to run the loop before passing the name to libgccjit: i.e. make name and try to create an empty file until success, after that, the file is ours (and due to the special permissions in /tmp can't be taken away) -- then pass to libgccjit. At least this is the "standard pattern" for this. Ligccjit should just not be surprised that there is a file and simply overwrite it. > > If not, then I think it can't be used safely unless > > *you* pre-create the file (e.g. with `make-temp-file`). >=20 > Are we sure? >=20 > Also if I pre-create the file with make-temp-file can't someone just > replace it even more easily with the infamous link before libgccjit > comes in? Not if they are another user, and /tmp (or whatever temporary dir it is) has the right permission bits set (that "sticky bit" on the directory only allows the file owner to change the directory entry). Cheers --=20 t --PldgKDWZWy5HYt8/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCY/OswAAKCRAFyCz1etHa RjUwAJ9aCGaVq+Fm/jbvkFY4BNRKuE2/TACfYCnX9XQcUoueOKbMEJKg5Bkm0x4= =NX1n -----END PGP SIGNATURE----- --PldgKDWZWy5HYt8/--