View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001526 | Issue 8 drafts | System Interfaces | public | 2021-10-19 10:53 | 2024-06-11 09:12 |
| Reporter | geoffclare | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Enhancement Request |
| Status | Closed | Resolution | Accepted As Marked | ||
| 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 | See 0001526:0005600. | ||||
| 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: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. 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 robotto: <tt>"robert the robot"</tt> On page 1423 line 47536 section popen(), change: wfto: <tt>"wf"</tt> On page 1423 line 47542 section popen(), change: rfto: <tt>"rf"</tt> | ||||
| Tags | issue8 | ||||
| related to | 0001302 | Closed | 1003.1(2016/18)/Issue7+TC2 | Alignment with C17 |
|
|
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). |
|
|
> 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. |
|
|
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: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. 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 robotto: <tt>"robert the robot"</tt> On page 1423 line 47536 section popen(), change: wfto: <tt>"wf"</tt> On page 1423 line 47542 section popen(), change: rfto: <tt>"rf"</tt> |
| 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 0001526: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 |
