|Anonymous | Login||2021-10-22 16:06 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001524||[Issue 8 drafts] System Interfaces||Objection||Omission||2021-10-10 18:49||2021-10-11 09:12|
|Reporter||Don Cragun||View Status||public|
|Status||New||Product Version||Draft 2.1|
|Page Number||881, 882|
|Line Number||29973-29974, 30005-30013|
|Final Accepted Text|
|Summary||0001524: open() flags used by fopen()|
The lead-in to the table describing the open() flags used by fopen() on P882, L30005-30013 says:
The file descriptor associated with the opened stream shall be allocated and opened as if by a call to open( ) with the following flags:
but it doesn't say that additional flags can't silently be added to the given sets of flags. In fact, if you use the <tt>'e'</tt> or <tt>'x'</tt> characters in the mode string, other flags are required to be OR'ed into the flags listed in this table.
Implementations of fopen( ) should not be allowed to act as though flags such as O_DSYNC, O_NONBLOCK, etc. had been set when a file is opened.
Change the description of the <tt>'e'</tt> mode string character on P881, L29973-29974 from:
The underlying file descriptor shall have the FD_CLOEXEC flag atomically set, as if by the O_CLOEXEC flag to open( ).to:
The underlying file descriptor shall have the FD_CLOEXEC flag atomically set.
A change similar to the above will be needed for the description of the <tt>'x'</tt> mode string character on P881, L29975-29977 but I won't specify the details here because that text is being modified by changes for 0001302.
In the second column of the table header on P882, L30007 change:
open( ) Flagsto:
Initial open( ) Flags
After the table on P882, L30005-30013 add three new paragraphs (all CX shaded):
If, and only if, the <tt>'e'</tt> mode string character is specified, the O_CLOEXEC flag shall be OR'ed into the initial open( ) flags specified in the above table.
|Tags||No tags attached.|
This, I think, is going too far:
The implementation shall behave as if no other flags had been passed to open( ).
What it probably should say is something like:
Unless other implementation defined characters are present in the mode
string, the implementation shall behave as if no other flags had been
passed to open().
or something like that. That is, implementations should be allowed to
make extensions, for example, an 'N' in the mode string could specify O_NONBLOCK
(etc) if the implementation had a reason to desire something like that.
That is, it isn't important that the implementation never add other open
flags, only that it not do so unless use of an implementation extension
requests it to do so, so code using only standard mode strings won't be surprised.
While not directly related to this bug, it is worth nothing that nothing I
have even seen in the standard specifies what modes the standard open fds
(stdin, stdout, stderr) should have set, or not set (aside from read/write
That is, there's nothing I can see that says that applications are not
required to operate correctly if started with stdin with O_CLOFORK set
(assuming that flag gets added) or O_NONBLOCK, or that stdout cannot
have O_APPEND set. Any of that would be unusual to say the least,
but is any of it forbidden?
[Aside, obviously O_CLOEXEC cannot be set on any of those fds ...]
Don Cragun (manager)
Re Note: 0005501:
I would be happy to change the last paragraph of the additional text after the table to be:
When using mode strings specified by this standard, the implementation shall behave as if no other flags had been passed to open( ).
The penultimate line of the desired action ("Add a corresponding paragraph ...") is part of the literal text to be added. It should be deleted and a statement added at the bottom to handle this in the same way as for the 'x' description - something along the lines of:
A paragraph similar to the one for O_CLOEXEC above will be needed for O_EXCL when the 'x' mode string character is used, but I won't specify the details here because that text is being modified by changes for bug 1302.
|2021-10-10 18:49||Don Cragun||New Issue|
|2021-10-10 18:49||Don Cragun||Name||=> Don Cragun|
|2021-10-10 18:49||Don Cragun||Section||=> fopen()|
|2021-10-10 18:49||Don Cragun||Page Number||=> 881, 882|
|2021-10-10 18:49||Don Cragun||Line Number||=> 29973-29974, 30005-30013|
|2021-10-10 18:53||Don Cragun||Desired Action Updated|
|2021-10-10 23:45||kre||Note Added: 0005501|
|2021-10-10 23:51||kre||Note Added: 0005502|
|2021-10-11 03:45||Don Cragun||Note Added: 0005503|
|2021-10-11 09:12||geoffclare||Note Added: 0005504|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|