manual: fopen with the x flag does not follow ISO C11

ISO C11 requires that the new file is created locked, something
that our implementation does not do.  Changing that would impact
backwards compatibility, particularly if the C11 requirement of
“exclusive (also known as non-shared) access to the extent that
the underlying system supports exclusive access” is read to imply
mandatory locking.

-----
 manual/stdio.texi | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

On 12/9/19 11:16 AM, Florian Weimer wrote:

> -The @samp{x} modifier is part of @w{ISO C11}.
> +@strong{Portability Note:} Some standards describe the @samp{x}
> +specifier with different semantics, requiring that exclusive,
> +mandatory file locking is enabled for the new file.  The
> +implementation in @theglibc{} follows existing practice and only
> +passes the @code{O_EXCL} flag to the kernel.

As far as I can see, the intent of C11 is that 'fopen' with "x" simply 
maps to POSIX 'open' with O_EXCL. There's no requirement in C11 that the 
program must have exclusive use of the file during the entire period 
that the file is open. Instead, the exclusion can be during the original 
access, during the opening of the file so that we know we created the file.

Also, the word "mandatory" doesn't seem right here. C11 says that 
'fopen' with "x" gets you exclusive access "to the extent that the 
underlying system supports exclusive access", which doesn't sound like 
"mandatory". POSIX declined to standardize mandatory locking, and C11 
doesn't standardize it either.

* Paul Eggert:

> On 12/9/19 11:16 AM, Florian Weimer wrote:
>
>> -The @samp{x} modifier is part of @w{ISO C11}.
>> +@strong{Portability Note:} Some standards describe the @samp{x}
>> +specifier with different semantics, requiring that exclusive,
>> +mandatory file locking is enabled for the new file.  The
>> +implementation in @theglibc{} follows existing practice and only
>> +passes the @code{O_EXCL} flag to the kernel.
>
> As far as I can see, the intent of C11 is that 'fopen' with "x" simply
> maps to POSIX 'open' with O_EXCL. There's no requirement in C11 that
> the program must have exclusive use of the file during the entire
> period that the file is open. Instead, the exclusion can be during the
> original access, during the opening of the file so that we know we
> created the file.
>
> Also, the word "mandatory" doesn't seem right here. C11 says that
> 'fopen' with "x" gets you exclusive access "to the extent that the
> underlying system supports exclusive access", which doesn't sound like
> "mandatory". POSIX declined to standardize mandatory locking, and C11
> doesn't standardize it either.

To be honest, I'm not really interested in what the C standard says.

However, it seems that people think that glibc implements the x
specifier, and that the standard requires various additional things that
glibc does not implement, ranging from locking to special file modes
(similar to mkstemp).

I think it is worth clarifying that glibc's x specifier only results in
O_EXCL and nothing else.

Thanks,
Florian

On 12/10/19 4:18 AM, Florian Weimer wrote:
> I think it is worth clarifying that glibc's x specifier only results in
> O_EXCL and nothing else.

Although the glibc manual already says "x" means O_EXCL, I agree it'd be 
nice for it to also say that this behavior is compatible with ISO C. 
That is, the manual shouldn't imply that some standards require behavior 
other than O_EXCL.

How about the attached patch?

A different topic: shouldn't the manual refer to ISO C18 (the current 
version of the C standard) rather than to ISO C11 (the previous one)?

On Dez 10 2019, Paul Eggert wrote:

> A different topic: shouldn't the manual refer to ISO C18 (the current
> version of the C standard) rather than to ISO C11 (the previous one)?

I think it makes sense to keep C11 which is when it was added.
Otherwise it should rather say just ISO C, so that it doesn't have to be
changed each time the standard is updated.

Andreas.

* Paul Eggert:

> On 12/10/19 4:18 AM, Florian Weimer wrote:
>> I think it is worth clarifying that glibc's x specifier only results in
>> O_EXCL and nothing else.
>
> Although the glibc manual already says "x" means O_EXCL, I agree it'd
> be nice for it to also say that this behavior is compatible with ISO
> C. That is, the manual shouldn't imply that some standards require
> behavior other than O_EXCL.
>
> How about the attached patch?

I'm not sure about the “common practice” part.  This would need
checking.  I would just drop it.

> A different topic: shouldn't the manual refer to ISO C18 (the current
> version of the C standard) rather than to ISO C11 (the previous one)?

I do not have a copy of C18, but it seems the wording is different
there.  As Andreas said, the x specifier was first mentioned in C11.

Thanks,
Florian

On Dez 11 2019, Florian Weimer wrote:

> I do not have a copy of C18

C18 is N2176.

> but it seems the wording is different there.

C18 has exactly the same words.

Andreas.

On 12/11/19 1:53 AM, Florian Weimer wrote:
> I'm not sure about the “common practice” part.  This would need
> checking.  I would just drop it.

Sure, that's fine. I installed the attached.

I left the "ISO C11" vs "ISO C" issue for some later time.

* Paul Eggert:

> -The @samp{x} modifier is part of @w{ISO C11}.
> +The @samp{x} modifier is part of @w{ISO C11}, which says the file is
> +created with exclusive access; in @theglibc{} this means the
> +equivalent of @code{O_EXCL}.

This looks good to me, thanks.

Florian

On Wed, Dec 11, 2019 at 12:42 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> I left the "ISO C11" vs "ISO C" issue for some later time.

I think it's important for the manual to document which revision of
the C standard a feature was added in, for everything that's newer
than C1999.  I could even argue for C1989.

zw

On Wed, 11 Dec 2019, Zack Weinberg wrote:

> On Wed, Dec 11, 2019 at 12:42 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> >
> > I left the "ISO C11" vs "ISO C" issue for some later time.
> 
> I think it's important for the manual to document which revision of
> the C standard a feature was added in, for everything that's newer
> than C1999.  I could even argue for C1989.

However, it should generally not try to distinguish between bug-fix 
variants of the same standard version (such as the 2011 and 2018 editions 
of ISO C, or the 2008, 2013, 2016 and 2018 editions of POSIX).  (There may 
be rare exceptions, e.g. where some interface was marked obsolescent in a 
bug-fix revision, as was the case with ATOMIC_VAR_INIT in the 2018 edition 
of ISO C.)

11.12.2019 19:43 Zack Weinberg <zackw@panix.com> wrote:
> [...]
> I think it's important for the manual to document which revision of
> the C standard a feature was added in, for everything that's newer
> than C1999.  I could even argue for C1989.

FWIW, I agree.  It's good to know whether a feature is old and it's
safe to assume it's going to work on all systems vs. it's rather new
and requires a newer system.

Regards,

Rafal