Date: Fri, 27 May 2022 13:23:43 +0000
Dear WG14/WG21 liason,
Last WG14 meeting N2857: C2x fopen("x") and fopen("a") v2 was discussed,
and the committee sought wording refinements and the removed second half
of fopen("x") to be supplied as a new fopen option, for which I have
chosen "p".
As time is running short for the C23 IS, can I get feedback on proposed
wording for the C23 IS on the following, which will also affect C++
iostreams:
fopen("x"):
Opening a file with exclusive mode (\code{'x'} as the last character in
the mode argument) fails if the file already exists or cannot be
created. The check for the existence of the file and the creation of the
file if it does not exist is atomic with respect to other threads and
processes. If the implementation is not capable of performing the check
for the existence of the file and the creation of the file atomically,
it shall fail setting \code{errno} to \code{ENOTSUP} instead of
performing a non-atomic check and creation.
[Main change: Removal of second choice of implementation, which no major
implementation chose in any case]
fopen("a"):
Opening a file with append mode (\code{'a'} as the first character in
the mode argument) causes all subsequent writes to the file to be forced
to the current end-of-file at the point of buffer flush or actual
write}, regardless of intervening calls to the \code{fseek},
\code{fsetpos}, or \code{rewind} functions. Incrementing the current
end-of-file by the amount of data written is atomic with respect
to other threads writing to the same file provided the file was also
opened in append mode. If the implementation is not capable of
incrementing the current end-of-file atomically, it shall fail setting
\code{errno} to \code{ENOTSUP} instead of performing
non-atomic end-of-file writes.} In some implementations, opening a
binary file with append mode (\code{'b'} as the second or third
character in the above list of \code{mode} argument values) may
initially position the file position indicator for the stream beyond the
last data written, because of null character padding.
[Main change: increment of end of file to become atomic]
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")]
My thanks to Robert Seacord and Nick Stoughton for their private email
work on this wording.
Niall
Last WG14 meeting N2857: C2x fopen("x") and fopen("a") v2 was discussed,
and the committee sought wording refinements and the removed second half
of fopen("x") to be supplied as a new fopen option, for which I have
chosen "p".
As time is running short for the C23 IS, can I get feedback on proposed
wording for the C23 IS on the following, which will also affect C++
iostreams:
fopen("x"):
Opening a file with exclusive mode (\code{'x'} as the last character in
the mode argument) fails if the file already exists or cannot be
created. The check for the existence of the file and the creation of the
file if it does not exist is atomic with respect to other threads and
processes. If the implementation is not capable of performing the check
for the existence of the file and the creation of the file atomically,
it shall fail setting \code{errno} to \code{ENOTSUP} instead of
performing a non-atomic check and creation.
[Main change: Removal of second choice of implementation, which no major
implementation chose in any case]
fopen("a"):
Opening a file with append mode (\code{'a'} as the first character in
the mode argument) causes all subsequent writes to the file to be forced
to the current end-of-file at the point of buffer flush or actual
write}, regardless of intervening calls to the \code{fseek},
\code{fsetpos}, or \code{rewind} functions. Incrementing the current
end-of-file by the amount of data written is atomic with respect
to other threads writing to the same file provided the file was also
opened in append mode. If the implementation is not capable of
incrementing the current end-of-file atomically, it shall fail setting
\code{errno} to \code{ENOTSUP} instead of performing
non-atomic end-of-file writes.} In some implementations, opening a
binary file with append mode (\code{'b'} as the second or third
character in the above list of \code{mode} argument values) may
initially position the file position indicator for the stream beyond the
last data written, because of null character padding.
[Main change: increment of end of file to become atomic]
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")]
My thanks to Robert Seacord and Nick Stoughton for their private email
work on this wording.
Niall
Received on 2022-05-27 13:23:45