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
0001810 [Issue 8 drafts] System Interfaces Editorial Clarification Requested 2024-02-10 17:41 2024-04-15 16:00
Reporter alanc View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Resolved   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 Note: 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
Attached Files

- Relationships
related to 0001809Resolved close() guidance to use fclose() should also discuss fdopen() 

-  Notes
(0006652)
alanc (reporter)
2024-02-12 19:09

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.
(0006744)
geoffclare (manager)
2024-04-11 11:02

Adding some sort of warning about the fclose() issue raised in the bug description is fine. However, I think Note: 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.)
(0006749)
alanc (reporter)
2024-04-11 20:48

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.)
(0006750)
geoffclare (manager)
2024-04-15 15:59

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().

- Issue History
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 => Note: 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


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