On Thu, 30 Sept 2021 at 15:52, Niall Douglas via Lib-Ext <
lib-ext_at_[hidden]> wrote:

> On 30/09/2021 15:37, Jens Maurer via Lib-Ext wrote:
> > On 30/09/2021 15.47, Niall Douglas via Lib-Ext wrote:
> >> On 30/09/2021 14:25, Jonathan Wakely via Lib-Ext wrote:
> >>
> >>> I could get the paper written for the next mailing, if LEWG can answer
> >>> the two questions below.
> >>>
> >>> *1) Does this have any chance of getting through LEWG in time for
> C++23?*
> >>
> >> So long as WG21 replicates the exact semantics and wording for exclusive
> >> from C2x, I think this safe.
> >>
> >> (Note: I submitted a fix to the C2x wording some time ago, I believe the
> >> current wording is substantially what I submitted, and if so, then it is
> >> correct)
> >
> > C23 (draft) currently says (source: WG14 N2596):
> >
> > "Opening a file with exclusive mode ( ’x’ as the last character in the
> mode argument) fails if the file
> > already exists or cannot be created. Otherwise, the file is created with
> exclusive (also known as
> > non-shared) access to the extent that the underlying system supports
> exclusive access."
> >
> > That seems to be not the semantics that Jonathan is interested in,
> > i.e. getting an error if the file already exists, but otherwise not
> > changing the access semantics.
>
> Yeah the above is the old wording. I thought Robert Secord from WG14 was
> supposed to have fixed it?
>
> Here is a copy and paste from my email proposing improved wording:
>
> > --- cut ---
> > 5 Opening a file with exclusive mode (’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 shall be atomic with respect to other threads
> > executing fopen upon the same file, if ’x’ is also specified to that
> > fopen. If the implementation is not capable of performing the check for
> > the existence of the file and the creation of the file atomically, it
> > should fail instead of performing a non-atomic check and creation.
> >
> > 6 Opening a file with append mode (’a’ as the first character in the
> > mode argument) causes all subsequent writes to the file to be forced to
> > the then current end-of-file. The incrementing of the current
> > end-of-file by the amount of data written shall be atomic with respect
> > to other threads executing writes upon the same file. If the
> > implementation is not capable of performing the incrementing of the
> > current end-of-file atomically, it should fail instead of performing
> > non-atomic end-of-file writes. In some implementations, opening a binary
> > file with append mode (’b’ as the second or third character in the
> above
> > list of mode argument values) may initially position the file position
> > indicator for the stream beyond the last data written, because of null
> > character padding.
> > --- cut ---
> >
> > In terms of risk of breaking existing implementation:
> >
> > glibc already implements ’x’ meeting the as above specification. I
> also
> > checked these implementations:
> >
> > - FreeBSD: As above
> > - NetBSD: As above
> > - OpenBSD: As above
> > - MacOS: As above
> > - VS2019: ’x’ not supported
> > - QNX: ’x’ not supported
> > - HPUX: ’x’ not supported
> >
> > I added the specific clause that if the implementation cannot implement
> > this feature atomically, it should fail. The feature is worse than
> > useless if it is not atomic - it leads to code which appears to work,
> > but in fact has a race condition, because portable code expects this to
> > exclude concurrent users of the file. This addresses Rajan's comment
> > regarding implementation burden - if an implementation cannot implement
> > this atomically, it can always return failure. This traps portable code
> > expecting atomicity from corrupting people's data on incapable systems.
> > I strongly advise choosing to not corrupt people's data.
>
> I stand by everything I said above.
>
> If C23 draft has its current wording, I recommend in the strongest
> possible terms that WG21 not adopt support for fopen("x"), not least
> that it conflates "exclusive creation" with "exclusive access", which is
> completely unportable behaviour which will cause data loss and
> unpleasant surprise.
>
>
While I understand your argument and have some sympathy with it, I think in
practice your survey shows that either the feature is implemented as you
want, or not at all (because the C library is stuck in the past).

I really just want to align C++ with C11. If C2x strengthens it, that's
great, we'll get it for free. If C doesn't strengthen it (because they want
to support non-POSIX systems where they can't guarantee those semantics,
but still want some pretense of exclusive access), then I'd still like C++
to be aligned with that. In practice, most C++ implementations will get the
stronger semantics anyway.