On Thu, Sep 30, 2021 at 10:52 AM 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?

My liaison senses were tingling. :-D The only paper I'm aware of on
the topic is: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2357.htm

The meeting minutes on the discussion of that paper are in:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2377.pdf

Some interesting snippets from the minutes:

*Straw poll: Do we want to incorporate N2357’s second proposed change
into C2X? 11/1/11 (In favor, Opposed, Abstain)
*Straw poll: Do we want any changes to 7.21.5.3 p5 regarding the
“exclusive” in exclusive file access? 11/1/12 (In favor, Opposed,
Abstain)

Niall: I can propose alternative wording. I intend to write exactly
what POSIX does

So neither poll gained consensus, and I think we're waiting on Niall
to produce the follow-up paper.

~Aaron

>
> 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.
>
> Niall
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2021/09/20550.php