Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001526 [Issue 8 drafts] System Interfaces Objection Enhancement Request 2021-10-19 10:53 2021-10-21 08:48
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Open  
Status New   Product Version Draft 2.1
Name Geoff Clare
Organization The Open Group
User Reference
Section fdopen()
Page Number 823
Line Number 28083-28093
Final Accepted Text
Summary 0001526: Update fdopen() mode description to match new fopen() terminology
Description The new 'e' and 'x' mode string characters for fopen() have been accounted for on the fdopen() page using "prefix" terminology, which is being changed for fopen() via bug 0001302 (C17 alignment). The fdopen() page should change to match the new terminology, but the need for this change does not result (directly) from C17 alignment, so it is being handled by a separate bug instead of in 1302.

The current wording is also vague about what happens if there is a mismatch between the O_APPEND flag on the open file description and the use of 'w' versus 'a' in the mode. The only clue is that the rationale states "a good implementation of append (a) mode would cause the O_APPEND flag to be set", which implies that it is intentional that both behaviours are allowed when O_APPEND is clear and 'a' is used. I tried test programs on Linux (glibc), Solaris, MacOS and HP-UX, and the results were:

* Only Linux set O_APPEND if it was clear when using "a"
* All four left O_APPEND set if it was set when using "w"

Therefore the suggested changes make it unspecified for "a" but mandate leaving O_APPEND set for "w".

As an editorial matter, the use of the phrase "Open a file" is also problematic since fdopen() does not actually open a file.

Finally, the new changes include a typographical conventions change to use quotes around mode characters instead of italicising them. This change is also needed on the popen() page for consistency.
Desired Action On page 823 line 28083 section fdopen(), change:
The mode argument points to a character string, which shall also be valid for fopen(). The string prefix shall have the following effects:

r or rb
Open a file for reading.
w or wb
Open a file for writing.
a or ab
Open a file for writing at end-of-file.
r+ or rb+ or r+b
Open a file for update (reading and writing).
w+ or wb+ or w+b
Open a file for update (reading and writing).
a+ or ab+ or a+b
Open a file for update (reading and writing) at end-of-file.
The meaning of these flags is exactly as specified in fopen(), except that modes beginning with w shall not cause truncation of the file, and the use of x shall have no effect. The FD_CLOEXEC flag of fildes shall be unchanged if e was not present, and shall be set if e is present.
to:
The mode argument points to a character string that is valid for fopen(). If the string begins with one of the following characters, then the stream shall be associated with fildes as specified. Otherwise, the behavior is undefined.

<tt>'r'</tt>
If mode includes <tt>'+'</tt>, the associated stream shall be open for update (reading and writing); otherwise, the stream shall be open for reading only.
<tt>'w'</tt>
If mode includes <tt>'+'</tt>, the associated stream shall be open for update (reading and writing); otherwise, the stream shall be open for writing only. The file shall not be truncated by the fdopen() call. If the open file description referenced by fildes has O_APPEND set, it shall remain set.
<tt>'a'</tt>
If mode includes <tt>'+'</tt>, the associated stream shall be open for update (reading and writing); otherwise, the stream shall be open for writing only. If the open file description referenced by fildes has O_APPEND clear, it is unspecified whether O_APPEND is set by the fdopen() call or remains clear.
The presence of <tt>'x'</tt> in mode shall have no effect. The FD_CLOEXEC flag of fildes shall be unchanged if <tt>'e'</tt> is not present, and shall be set by the fdopen() call if <tt>'e'</tt> is present.

On page 824 line 28124 section fdopen(), change:
The meanings of the mode arguments of fdopen() and fopen() differ. With fdopen(), open for write (w or w+) does not truncate, and append (a or a+) cannot create for writing. The mode argument formats that include a b are allowed for consistency with the ISO C standard function fopen(). The b has no effect on the resulting stream. Although not explicitly required by this volume of POSIX.1-202x, a good implementation of append (a) mode would cause the O_APPEND flag to be set. Since fdopen() does not create a file, the x mode modifier is silently ignored. The e mode modifier is ...
to:
The meanings of the mode arguments of fdopen() and fopen() differ. With fdopen(), write (<tt>'w'</tt>) mode cannot create or truncate a file, and append (<tt>'a'</tt>) mode cannot create a file. Inclusion of a <tt>'b'</tt> in the mode argument is allowed for consistency with fopen(); the <tt>'b'</tt> has no effect on the resulting stream. Implementations differ as to whether specifying append (<tt>'a'</tt>) mode causes the O_APPEND flag to be set if it was clear, but they are encouraged to do so. Since fdopen() does not create a file, the <tt>'x'</tt> mode modifier is silently ignored. The <tt>'e'</tt> mode modifier is ...

On page 1421 line 47441, 47447, 47453 section popen(), and
page 1422 line 47499 section popen(), and
page 1423 line 47508, 47509, 47525, 47532, 47533 section popen(), and
page 1428 line 47785 section popen():
change r, w, and e to <tt>'r'</tt>, <tt>'w'</tt>, and <tt>'e'</tt>, respectively.

On page 1422 line 47505 section popen(), change:
The behavior of popen() is specified for values of mode of r, w, re, and we. Other modes such as rb and wb might ...
to:
The behavior of popen() is specified for values of mode of <tt>"r"</tt>, <tt>"w"</tt>, <tt>"re"</tt>, and <tt>"we"</tt>. Other modes such as <tt>"rb"</tt> and <tt>"wb"</tt> might ...

On page 1423 line 47508 section popen(), change:
robert the robot
to:
<tt>"robert the robot"</tt>

On page 1423 line 47536 section popen(), change:
wf
to:
<tt>"wf"</tt>

On page 1423 line 47542 section popen(), change:
rf
to:
<tt>"rf"</tt>

Tags No tags attached.
Attached Files

- Relationships
related to 0001302Resolved 1003.1(2016/18)/Issue7+TC2 Alignment with C17 

-  Notes
(0005507)
kre (reporter)
2021-10-19 16:29
edited on: 2021-10-19 16:32

What's the effect if fd has O_APPEND set and there is
     fdopen(fd, "r+");
??

That seems to be ignored in the suggested text. (O_APPEND shouldn't
matter for the "r" case, one way or the other).

I also wonder about the requirement that 'b' be ignored for fdopen().
That's certainly what will happen if binary made is something selected
at the kernel open level (O_BINARY) but is it forbidden for stdio to
implement different I/O mechanisms for text & binary modes? That is,
if stdio itself is doing something different based upon whether or not
'b' is in the open mode, why would it matter if the FILE* was created by
fopen() or fdopen()? The 'b' should have the same effect in both cases.
In some systems where O_BINARY does make a difference, it might also be
possible to turn that on or off dynamically, just like is suggested as
a possibility for O_APPEND with "a" mode).

Lastly, is there any prohibition (or stated to be undefined or unspecified
anywhere) on the same underlying fd being the fd for more than one stdio
stream? If there is not, then what is the effect of fdopen(fd, "w")
followed by fdopen(fd, "a") (resulting in 2 different FILE*'s). Obviously
it would be up to the application to sequence output so it makes sense,
but the underlying fd would either have O_APPEND (in a "good implementation"
set by the "a") or not, and that would affect the "w" FILE* as well.

If there is such a prohibition, how does that apply to the common case where
stdin/stdout/stderr all share one underling file (ie: they are fds 0, 1, and 2
but they get created by in = open("/dev/ttyX", O_RDWR); out=dup(in); err=dup(in);
(starting from a state where everything was closed). In that
state there's just one O_APPEND or O_BINARY for all 3 of them (only the O_CLO*
flags affect just the file descriptor). That's effectively sharing a fd
(even though the numbers vary - and for the purposes of the previous paragraph,
is just the same as if the fds were the same).

(0005508)
geoffclare (manager)
2021-10-21 08:48

> What's the effect if fd has O_APPEND set and there is
> fdopen(fd, "r+");

Good catch. I tried this (and r and w+ for completeness) on the same four systems and they all left O_APPEND set. So I think the statement for 'w': "If the open file description referenced by fildes has O_APPEND set, it shall remain set" should be added to 'r' as well.

> (O_APPEND shouldn't matter for the "r" case, one way or the other)

If fd has O_RDWR|O_APPEND then fdopen(fd, "r") shouldn't clear O_APPEND because the application could still write directly to fd and expect the data to be appended.

> I also wonder about the requirement that 'b' be ignored for fdopen().

It matches the requirement that 'b' is ignored for fopen() and freopen(). It's already required for fdopen() as well (via the normative reference to fopen(), but that reference is removed by these changes so this requirement now needs to be stated explicitly).

> Lastly, is there any prohibition (or stated to be undefined or unspecified
> anywhere) on the same underlying fd being the fd for more than one stdio
> stream? If there is not, then what is the effect of fdopen(fd, "w")
> followed by fdopen(fd, "a") (resulting in 2 different FILE*'s).

There is no prohibition, but there are rules (in XSH 2.5.1) that applications must follow when changing from one "handle" to another (in the case given, there are three handles: the two streams and the fd).

The second fdopen() must behave exactly as specified - the fact that there is already another stream that has the same fd underlying it has no bearing on how fdopen() behaves.

- Issue History
Date Modified Username Field Change
2021-10-19 10:53 geoffclare New Issue
2021-10-19 10:53 geoffclare Name => Geoff Clare
2021-10-19 10:53 geoffclare Organization => The Open Group
2021-10-19 10:53 geoffclare Section => fdopen()
2021-10-19 10:53 geoffclare Page Number => 823
2021-10-19 10:53 geoffclare Line Number => 28083-28093
2021-10-19 10:58 geoffclare Relationship added related to 0001302
2021-10-19 16:29 kre Note Added: 0005507
2021-10-19 16:32 kre Note Edited: 0005507
2021-10-21 08:48 geoffclare Note Added: 0005508


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker