[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Finalizing 'inhibit-automatic-native-compilation'

From: tomas
Subject: Re: Finalizing 'inhibit-automatic-native-compilation'
Date: Mon, 20 Feb 2023 18:24:23 +0100

On Mon, Feb 20, 2023 at 04:07:59PM +0000, Andrea Corallo wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> >>> `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).
> 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

> > If not, then I think it can't be used safely unless
> > *you* pre-create the file (e.g. with `make-temp-file`).
> Are we sure?
> 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).


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]