On 27/05/2022 17:50, Joseph Myers via Liaison wrote:
> On Fri, 27 May 2022, Ville Voutilainen via Liaison wrote:
>
>> Can you briefly explain what existing practice the new "p" flag is based
 on?
>
> I'm supposing Linux O_TMPFILE. That's passed to open() along with a path
> to a directory, and the proposed text seems rather underspecified about
> what the semantics of the path passed to fopen with "p" would be - *how*
> it's intended to specify the file system for the file.

Yes Linux O_TMPFILE would do. On Windows, CreateFile() with dwShareMode
= FILE_SHARE_DELETE and dwCreationDisposition = CREATE_NEW and a unique
name followed by SetFileInformationByHandle with FileInformationClass =
FileDispositionInformationEx and FILE_DISPOSITION_INFORMATION_EX.Flags
set to FILE_DISPOSITION_DELETE|FILE_DISPOSITION_POSIX_SEMANTICS to make
the uniquely named file entry to immediately disappear. Thanks to
dwShareMode not permitting anybody else to open the file for access,
this is secure. This is what I was referring to earlier when I said
Linux and Windows have the necessary syscall support.


The current proposed wording for "p" is:

--- cut ---
Opening a file with private mode (\code{'p'} as the last character in
the mode argument) creates a file whose contents can not be accessed by
other means at any point in time, and whose \code{filename} may be
ignored by implementations except to identify which storage ought to
hold the file. If the implementation is not capable of creating private
files, it shall fail setting \code{errno} to \code{ENOTSUP}.
--- cut ---

 From your comment would this be better?

--- cut ---
Opening a file with private mode (\code{'p'} as the last character in
the mode argument) creates a file whose contents can not be accessed by
other means at any point in time, but is as if created at
\code{filename}. If the implementation is not capable of creating
private files, it shall fail setting \code{errno} to \code{ENOTSUP}.
--- cut ---

Niall