On 27/05/2022 15:23, Ville Voutilainen wrote:

>> fopen("p"):
>>
>> Opening a file with private mode (\code{'p'} as the last character in
>> the mode argument) creates a file whose contents no other thread nor
>> process can access via the filing system at any point in time, and whose
>> entry may or may not appear in the filing system (that is, the value of
>> \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}.
>>
>> [Main change: this is new, it is a specific choice of implementation for
>> the formerly second choice of implementation of C11 fopen("x")]
>
> Why "filing system"? Don't we all call them file systems?

It turns out that the C standard never mentions file systems (I assume
because some implementations may have none), so I suppose we need to not
do so here either.

How about this instead?

--- 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 ---

> Can you briefly explain what existing practice the new "p" flag is based
 on?

C11's fopen("x") had two choices of implementation (exclusivity of
creation and exclusivity of use), my paper removes the second choice
entirely (no implementation we know of chose it anyway). However some on
the committee wanted the second meaning of "exclusivity" (exclusivity of
use) to be retained via a new fopen option.

Proposed std::file_handle::temp_inode() does the exact same thing as
fopen("p") - "give me a scratch file exclusive for me to use".

In terms of existing practice, to my knowledge only Linux and Windows
have the syscall support to implement this *securely*. If you don't care
about "securely", any POSIX implementation since year dot can do this
(create the file, immediately unlink it).

I think we should care about this being secure, as the ability to store
secrets not in memory but in a private scratch file which is guaranteed
to disappear on process exit is valuable in my opinion. This would make
fopen("p") ENOTSUP on all current platforms except for Linux and
Windows, at least until kernels get upgraded. As a new fopen letter, I
think this acceptable, others may not.

Niall