View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001810 | Issue 8 drafts | System Interfaces | public | 2024-02-10 17:41 | 2024-04-15 16:00 |
| Reporter | alanc | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Resolved | Resolution | Accepted As Marked | ||
| Product Version | Draft 4 | ||||
| Name | Alan Coopersmith | ||||
| Organization | Oracle Solaris Engineering | ||||
| User Reference | |||||
| Section | fdopen() | ||||
| Page Number | 917 | ||||
| Line Number | 31300-31397 | ||||
| Final Accepted Text | 0001810:0006750 | ||||
| Summary | 0001810: fdopen() can only be used once per file descriptor | ||||
| Description | Nothing I see in the current description states that the same file descriptor should not be passed multiple times to fdopen(). But since the fclose() on the returned stream will also close the underlying file descriptor, once one stream returned from fdopen() for a given file descriptor is closed, all others will become broken or potentially refer to the wrong fd once the fd is reused. | ||||
| Desired Action | Add appropriate language to warn that applications must only use fdopen() once per file descriptor. | ||||
| Tags | tc1-2024 | ||||
| related to | 0001809 | Resolved | close() guidance to use fclose() should also discuss fdopen() |
|
|
After further reflection, I believe the warning should be that applications must not use fdopen() on an fd already associated with a stdio stream, whether that be an fd they already called fdopen() on, an fd returned by fileno() on an existing stream, the default fds (0, 1, 2) associated with stdin/stdout/stderr, etc. |
|
|
Adding some sort of warning about the fclose() issue raised in the bug description is fine. However, I think 0001810:0006652 goes too far. As long as the rules in XSH 2.5.1 "Interaction of File Descriptors and Standard I/O Streams" are followed, and the fclose() issue is taken into account, it is possible for an application to have two streams with the same underlying file descriptor and suffer no ill effects. (I can't think of a reason why an application would want to do this, but the standard should not warn against it just because its developers lack imagination.) For similar reasons, I think any warning about the fclose() issue should not advise against having two streams with the same underlying file descriptor, but rather advise about the need to take care when closing them. (In particular, the application needs to ensure that no operations that open a file descriptor are performed in between the two fclose() calls, otherwise the second could close the newly opened fd instead of getting an EBADF error.) |
|
|
The engineer who originally brought this to my attention also suggested there could be an fdclose() function that closes the stdio stream but not the underlying file descriptor, which could make things safer if someone did actually have a valid use case for using the same fd for multiple streams. (Though while the fdclose() name nicely parallels fdopen() it is a bit confusing of a name for something that explicitly doesn't close the fd - perhaps something more like fddetach() would work better.) |
|
|
After page 899 line 30638, add to fclose() APPLICATION USAGE:If the file descriptor associated with the stream has already been closed, fclose() fails with an [EBADF] error (after it deallocates the stream). However, in the event that the same file descriptor number is allocated by some other operation (such as dup(), fopen(), open(), pipe(), socket(), and so forth), before fclose() is called, the fclose() call will close this newly allocated file descriptor instead. Therefore, applications which close the file descriptor before calling fclose() should ensure that they do not perform any file open operations in between closing the file descriptor and calling fclose(). This also applies in the event that two streams have the same associated file descriptor; calling fclose() on the first stream closes the file descriptor associated with both streams, and then calling fclose() on the second stream has the same risk described above. See also xref to P522, L18532 XSH 2.5.1 Interaction of File Descriptors and Standard I/O Streams. After page 918 line 31349, add to fdopen() APPLICATION USAGE: See also the APPLICATION USAGE for fclose(). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-02-10 17:41 | alanc | New Issue | |
| 2024-02-10 17:41 | alanc | Name | => Alan Coopersmith |
| 2024-02-10 17:41 | alanc | Organization | => Oracle Solaris Engineering |
| 2024-02-10 17:41 | alanc | Section | => fdopen() |
| 2024-02-10 17:41 | alanc | Page Number | => 917 |
| 2024-02-10 17:41 | alanc | Line Number | => 31300-31397 |
| 2024-02-10 18:57 | Don Cragun | Relationship added | related to 0001809 |
| 2024-02-12 19:09 | alanc | Note Added: 0006652 | |
| 2024-04-11 11:02 | geoffclare | Note Added: 0006744 | |
| 2024-04-11 20:48 | alanc | Note Added: 0006749 | |
| 2024-04-15 15:59 | geoffclare | Note Added: 0006750 | |
| 2024-04-15 16:00 | geoffclare | Final Accepted Text | => 0001810:0006750 |
| 2024-04-15 16:00 | geoffclare | Status | New => Resolved |
| 2024-04-15 16:00 | geoffclare | Resolution | Open => Accepted As Marked |
| 2024-04-15 16:00 | geoffclare | Tag Attached: tc1-2024 |
