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

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Florian Weimer-5
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(-)

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

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] manual: fopen with the x flag does not follow ISO C11

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.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] manual: fopen with the x flag does not follow ISO C11

Florian Weimer-5
* 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

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] manual: fopen with the x flag does not follow ISO C11

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?

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)?

0001-manual-clarify-fopen-with-the-x-flag.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] manual: fopen with the x flag does not follow ISO C11

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

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] manual: fopen with the x flag does not follow ISO C11

Florian Weimer-5
In reply to this post by Paul Eggert
* 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

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] manual: fopen with the x flag does not follow ISO C11

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

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] manual: fopen with the x flag does not follow ISO C11

Paul Eggert
In reply to this post by Florian Weimer-5
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.

0001-manual-clarify-fopen-with-the-x-flag.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] manual: fopen with the x flag does not follow ISO C11

Florian Weimer-5
* 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

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] manual: fopen with the x flag does not follow ISO C11

Zack Weinberg-2
In reply to this post by Paul Eggert
On Wed, Dec 11, 2019 at 12:42 PM Paul Eggert <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] manual: fopen with the x flag does not follow ISO C11

Joseph Myers
On Wed, 11 Dec 2019, Zack Weinberg wrote:

> On Wed, Dec 11, 2019 at 12:42 PM Paul Eggert <[hidden email]> 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.)

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] manual: fopen with the x flag does not follow ISO C11

Rafal Luzynski
In reply to this post by Zack Weinberg-2
11.12.2019 19:43 Zack Weinberg <[hidden email]> 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