On 30/09/2021 16:33, Jonathan Wakely wrote:

> > 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
>
> 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 would agree that all *modern* C libraries on the major platforms
implement it as I wrote. Which is unsurprising, as they implement POSIX.
But note this choice of implementation which also meets that normative
wording:

1. Create file, replacing any already there.
2. Immediately unlink file.
3. Now file can only be used exclusively.

Or, as Windows used to define "exclusive" in its legacy C library:

1. Create file with ShareMode = 0, replacing any already there.
2. Any attempt by anyone else to open that file fails with an
AccessDenied error code, which makes you think it's permissions on the
file, but those are in fact totally independent and probably do allow
access.

Or, best of all:

1. Create file, replacing any already there.
2. Take an exclusive mandatory lock on the file.
3. Other open file calls succeed, but any i/o on the file blocks forever
for no obvious reason.
4. If any handle to the same inode is closed in the program by any
thread, the exclusive lock immediately drops and all blocked i/o threads
across the system immediately wake.

I'm sure you agree that none of these is a helpful implementation choice
if the programmer was expecting a "first past the post creation"
semantic. Their code would horribly break. Standards are here to prevent
that kind of non-portable surprise.

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

It looks like we may be able to fix C2x before it ships. If so, I have
no issue with C++ supporting a strict definition of exclusive file open,
where exclusive means and only means "exclusive creation of new entry on
the file system".

Niall