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

Message ID 877e3571jh.fsf@oldenburg2.str.redhat.com
State New
Headers show
Series
  • manual: fopen with the x flag does not follow ISO C11
Related show

Commit Message

Florian Weimer Dec. 9, 2019, 7:16 p.m. UTC
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(-)

Comments

Paul Eggert Dec. 9, 2019, 7:50 p.m. UTC | #1
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.
Florian Weimer Dec. 10, 2019, 12:18 p.m. UTC | #2
* 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
Paul Eggert Dec. 10, 2019, 10:26 p.m. UTC | #3
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)?
Andreas Schwab Dec. 11, 2019, 8:58 a.m. UTC | #4
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.
Florian Weimer Dec. 11, 2019, 9:53 a.m. UTC | #5
* 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
Andreas Schwab Dec. 11, 2019, 9:59 a.m. UTC | #6
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.
Paul Eggert Dec. 11, 2019, 5:42 p.m. UTC | #7
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.
Florian Weimer Dec. 11, 2019, 5:46 p.m. UTC | #8
* 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
Zack Weinberg Dec. 11, 2019, 6:43 p.m. UTC | #9
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
Joseph Myers Dec. 11, 2019, 9:38 p.m. UTC | #10
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.)
Rafal Luzynski Dec. 11, 2019, 9:41 p.m. UTC | #11
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

Patch
diff mbox series

diff --git a/manual/stdio.texi b/manual/stdio.texi
index bbd3061bab..33a0250a9a 100644
--- a/manual/stdio.texi
+++ b/manual/stdio.texi
@@ -216,7 +216,11 @@  exists, @code{fopen} fails rather than opening it.  If you use
 file.  This is equivalent to the @code{O_EXCL} option to the
 @code{open} function (@pxref{Opening and Closing Files}).
 
-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.
 @end table
 
 The character @samp{b} in @var{opentype} has a standard meaning; it