View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001524 | Issue 8 drafts | System Interfaces | public | 2021-10-10 18:49 | 2024-06-11 09:12 |
| Reporter | Don Cragun | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Omission |
| Status | Closed | Resolution | Accepted As Marked | ||
| Product Version | Draft 2.1 | ||||
| Name | Don Cragun | ||||
| Organization | |||||
| User Reference | |||||
| Section | fopen() | ||||
| Page Number | 881, 882 | ||||
| Line Number | 29973-29974, 30005-30013 | ||||
| Final Accepted Text | 0001524:0005582 | ||||
| Summary | 0001524: open() flags used by fopen() | ||||
| Description | 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. | ||||
| Desired Action | 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 | issue8 | ||||
| related to | 0001302 | Closed | 1003.1(2016/18)/Issue7+TC2 | Alignment with C17 |
|
|
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 modes). 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 ...] |
|
|
Re 0001524: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. |
|
|
Based on comments received in 0001524:0005501 and 0001524:0005504, I propose the following replacement for the Desired Action above: 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 two 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. Add a corresponding paragraph (also CX shaded) similar to the paragraph above for the O_CLOEXEC flag for the O_EXCL flag when <tt>'x'</tt> is in the mode string. |
|
|
Bug 0001302 has been resolved since this bug was submitted, so the proposed changes that overlap with 1302 need to be specified in the form "after applying bug 1302 change ..." The first requested change is not needed as it is being made by 1302. Likewise the similar change for 'x' is included in 1302. So the only changes needed are to the table and surrounding text. I suggest: On P882 L30005, after applying bug 1302 change: The file descriptor associated with the opened stream shall be allocated and opened as if by a call to open() using the following flags, with the addition of the O_CLOEXEC flag if mode includes 'e', and the O_EXCL flag if mode includes 'x' and either 'w' or 'a':to: The file descriptor associated with the opened stream shall be allocated and opened as if by a call to open() using the following flags: On P882 L30007, after applying bug 1302 change the third column of the table header from: open() Flagsto: Initial open() Flags After the table on P882 L30007-30013, add the following 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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 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 | |
| 2022-01-07 06:22 | Don Cragun | Note Added: 0005581 | |
| 2022-01-07 10:06 | geoffclare | Note Added: 0005582 | |
| 2022-01-07 10:07 | geoffclare | Relationship added | related to 0001302 |
| 2022-01-13 17:05 | geoffclare | Final Accepted Text | => 0001524:0005582 |
| 2022-01-13 17:05 | geoffclare | Status | New => Resolved |
| 2022-01-13 17:05 | geoffclare | Resolution | Open => Accepted As Marked |
| 2022-01-13 17:06 | geoffclare | Tag Attached: issue8 | |
| 2022-02-11 15:18 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 09:12 | agadmin | Status | Applied => Closed |
