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.

Niall