Fork#42561: MSVCRT.DLL implementation of POSIX dup2() function does not conform to POSIX.1
Open Date: 2021-06-22 23:34
Last Update: 2021-06-26 20:38
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/42561
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=42561
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2021-06-26 20:38 Updated by: keith
Comment:
Reply To eliz
... please note that AFAIK there's one more non-conformance between the MS dup2 and Posix: Posix mandates that "If the close operation fails to close fildes2, dup2() shall return -1 without changing the open file description to which fildes2 refers." The MS implementation doesn't do that: it leaves the original fildes2s file open, and changes fildes2 to refer to the same file as fildes descriptor. If you want to fix that issue as well, a simple wrapper will no longer be sufficient.
Thanks, Eli. I must be missing something, but I'm struggling to get my head around (even the concept of) the scenario which you describe. Do you have an example, or can you create one, to illustrate the effect, please?
FWIW, Microsoft's documentation makes no mention of any failure condition related to failure to close a pre-existing file descriptor association for fd2; it simply, and unequivocally, states that if any such association exists, it is closed, and that the return value is zero if the function succeeds, but if any (vaguely specified) error occurs, the return value will be -1. If the implementation behaves as Microsoft themselves document it, then failure to close fd2 should result in a return of -1, and thus matches the POSIX requirement. How could it be otherwise? If the function succeeds, with fd2 reassigned after failure to close the original association, what happens to the original file stream? Does the underlying OS file handle remain open, as an orphan? What happens to any _fileno() association within an associated FILE * structure?
---------------------------------------------------------------------
Ticket Status:
Reporter: keith
Owner: (None)
Type: Issues
Status: Open
Priority: 5 - Medium
MileStone: (None)
Component: WSL
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
I've been aware of this non-conformity for several years, yet it continues to trip me up, on occasion. Consider the code fragment:
int fd = open( "foo.txt", O_CREAT | O_EXCL, S_IREAD | S_IWRITE ); if( dup2( fd, STDOUT_FILENO ) != STDOUT_FILENO ) perror( "open" );On a POSIX.1 conforming platform, (with added support for the BSD standard S_IREAD and S_IWRITE macros), assuming that "foo.txt" is successfully opened, and bound to STDOUT_FILENO by the dup2() call, the condition dup2( fd, STDOUT_FILENO ) == STDOUT_FILENO will evaluate as TRUE, and the perror() call will not be invoked. However, on Windows, the same code, (assuming that errno is zero, immediately prior to its execution), will likely result in output (from perror(), which is invoked) similar to:
open: Success.
The reason for this disparity, given a function prototype of int dup2( int fd1, int fd2 ), is that, whereas POSIX.1 stipulates that the return value, following a successful invocation, shall be equal to fd2, the Microsoft implementation always returns zero, on success, regardless of the value of fd2.
To be fair to Microsoft, although their documentation does describe dup2() as a POSIX function (in name only), it indicates that it is a deprecated ("because [it doesn't] follow the Standard C rules for implementation-specific names" ... a rationale which would seem to not be endorsed by ISO/IEC, since dup2() is ratified as an international standard name, within ISO/IEC 9945, as it is in IEEE 1003.1-2017) alias for Microsoft's non-standard _dup2(), for which the documentation does indicate the non-conformity w.r.t. the return value stipulated by POSIX.1; however, given that this catches me out, every time I have occasion to use dup2(), and I don't think it is unreasonable to expect POSIX.1 conformity, when I call any function by its POSIX.1 name, I really would like to see this fixed in the MinGW implementation.
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/42561
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=42561