0001526: Update fdopen() mode description to match new fopen() terminology

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.

(0005600) geoffclare (manager) 2022-01-13 17:15	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. If the open file description referenced by fildes has O_APPEND set, it shall remain set. <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>

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
2022-01-13 17:15	geoffclare	Note Added: 0005600
2022-01-13 17:18	Don Cragun	Final Accepted Text	=> See Note: 0005600.
2022-01-13 17:18	Don Cragun	Status	New => Resolved
2022-01-13 17:18	Don Cragun	Resolution	Open => Accepted As Marked
2022-01-13 17:19	Don Cragun	Tag Attached: issue8
2022-02-11 15:23	geoffclare	Status	Resolved => Applied
2024-06-11 09:12	agadmin	Status	Applied => Closed

Aardvark Mark IV