From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Finalizing 'inhibit-automatic-native-compilation' Date: Mon, 20 Feb 2023 14:03:29 +0200 Message-ID: <833570wnla.fsf@gnu.org> References: <20230218.061335.1468428093197134401.tats%nobody@tats.iris.ne.jp> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12055"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, tats@debian.org, emacs-devel@gnu.org, spwhitton@spwhitton.name, 1021842@bugs.debian.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 20 13:03:45 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 1pU4tU-0002qP-LS for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Feb 2023 13:03:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pU4tB-0007YC-54; Mon, 20 Feb 2023 07:03:25 -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 1pU4t8-0007XW-F9 for emacs-devel@gnu.org; Mon, 20 Feb 2023 07:03:24 -0500 Original-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 ) id 1pU4t8-0007jJ-1T; Mon, 20 Feb 2023 07:03:22 -0500 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=On1+0xd+QDVOzZDKOyMAwfwUlTHsQvGMXRmEHvtx9Jw=; b=gC/E51CNFzbc EW+8DMJYKzz8UF77DFNz+xtwaIRXVIaw8fjDqGWjTIib/xiEr2okwHuSGmkOgJTagJfirhZpT9ZPA NetHAiKwCMupARBFlh/SLBapoQtjUuk4N62Va7YVUnWxhFhaJCkuK3oMW1FuLKFJLxudOb5ddwSlm xSf0RiRNUBlEiRpR9rSCphjPVhHxn20Rs72o5+Zs+RjBo4vxC2R6/P9KmdwlYdrWgbuxZQxko6EHH ftEHjssahnzhAlIh+wLg4s/NmnfJwrbrb96kETx2bSZaDeMUlSwNYHd+AouR1Uqi49gDPIoejmspU P8mjfJUvUTWILnYcFDswcA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pU4t7-0002Ml-BD; Mon, 20 Feb 2023 07:03:21 -0500 In-Reply-To: (message from Andrea Corallo on Mon, 20 Feb 2023 09:18:02 +0000) 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:303604 Archived-At: > From: Andrea Corallo > Cc: Tatsuya Kinoshita , emacs-devel@gnu.org, > spwhitton@spwhitton.name, 1021842@bugs.debian.org, Eli Zaretskii > > Date: Mon, 20 Feb 2023 09:18:02 +0000 > > Andrea Corallo writes: > > > Stefan Monnier writes: > > > >>> Shouldn't make-temp-file-internal return a non predictable file name? > >> > >> Nope. It's less predictable but it's still predictable. > >> > >>> Otherwise what's the point of using make-temp-file in the first place if > >>> the temporary name is predictable? > >> > >> `make-temp-name` uses `O_EXCL | O_CREAT` so as to close the race > >> condition: if someone predicated the filename, we detect it atomically > >> and we try again. > >> > >> You might like to check > >> > >> https://wiki.sei.cmu.edu/confluence/display/c/FIO21-C.+Do+not+create+temporary+files+in+shared+directories > > > > Thanks for the pointer. > > > > I'm still not really convinced we have a problem here with trampolines. > > With `make-temp-file' we are really only choosing the filename and > > suggesting it to libgccjit, this last one will perform the file > > creation. I'd be surprised if GCC does not handle this correctly, and > > in case shouldn't this be a GCC bug? > > > > OTOH on a slightly differnt subject and in light of this, I think we > > should probably backport e6043641d30 into emacs-30, so that eln files > > are created onace and only by libgccjit. Eli WDYT? > > And BTW, probably also in emacs-28 if we are doing another release. We don't want to make any enhancements in Emacs 28.3, just to plug the security hole. People who want enhancements will need to wait for Emacs 29.1, hopefully not too long.