Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000590 [1003.1(2008)/Issue 7] System Interfaces Objection Clarification Requested 2012-06-26 22:54 2012-07-12 15:56
Reporter Love4Boobies View Status public  
Assigned To ajosey
Priority normal Resolution Rejected  
Status Closed  
Name Bogdan Barbu
Organization
User Reference
Section dup, dup2 - duplicate an open file descriptor
Page Number ?
Line Number ?
Interp Status ---
Final Accepted Text see Note: 0001270
Summary 0000590: dup2 and signals
Description The standard does not specify what the state of the file descriptor is when dup2 is interrupted by a signal.
Desired Action I expect that in most cases, dup2 is implemented using close and fcntl. The former has been settled by a different bug report, and the latter does not permit EINTR when used with F_DUPFD. Hence, the logical solution would be to always close the descriptor if implementations agree.

Replace

[EINTR]
The dup2() function was interrupted by a signal.

with

[EINTR]
The dup2() function was interrupted by a signal and fildes2 was closed.

If you agree with the above, I will open a new proposal for posix_dup2 which would work in a similar fashion as posix_close.
Tags No tags attached.
Attached Files

- Relationships
related to 0000411Resolvedajosey adding atomic FD_CLOEXEC support 
related to 0000529Interpretation Requiredajosey fildes unspecified on close()'s [EINTR] 

-  Notes
(0001270)
eblake (manager)
2012-06-26 23:14

The standard is already clear that:

"If the close operation fails to close fildes2, dup2( ) shall return −1 without changing the open file description to which fildes2 refers." (line 24875)

That is, if dup2() is interrupted by a signal, then fildes2 was not closed.

Furthermore, the standard requires that dup2() be atomic with respect to all other functions in the standard by virtue of the fact that dup2() is async-signal-safe (line 16744); an implementation that implements dup2() by first calling close() and then calling dup() in such a manner that another thread or interrupt handler can see the state between the close operation and subsequent dup is not compliant. I don't think we have an issue here.

I will also point out that we have already have proposed the addition of dup3() as part of 0000411, that already provides a flag argument with enough spare bits that if any functionality is deemed necessary to fine-tune what happens when a dup operation is interrupted, we can implement it by defining one of those bits, instead of adding yet another function named posix_dup2(). But you first have to convince me that we even have an issue where it is even worth fine-tuning dup3() failure with regards to interrupts.

- Issue History
Date Modified Username Field Change
2012-06-26 22:54 Love4Boobies New Issue
2012-06-26 22:54 Love4Boobies Status New => Under Review
2012-06-26 22:54 Love4Boobies Assigned To => ajosey
2012-06-26 22:54 Love4Boobies Name => Bogdan Barbu
2012-06-26 22:54 Love4Boobies Section => dup, dup2 - duplicate an open file descriptor
2012-06-26 22:54 Love4Boobies Page Number => ?
2012-06-26 22:54 Love4Boobies Line Number => ?
2012-06-26 23:14 eblake Note Added: 0001270
2012-06-26 23:15 eblake Relationship added related to 0000411
2012-06-26 23:15 eblake Relationship added related to 0000529
2012-07-12 15:56 eblake Interp Status => ---
2012-07-12 15:56 eblake Final Accepted Text => see Note: 0001270
2012-07-12 15:56 eblake Status Under Review => Closed
2012-07-12 15:56 eblake Resolution Open => Rejected


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