[Bug stdio/15589] freopen would close oldfd even though oldfd is same as newfd

["eblake at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=15589

Eric Blake <eblake at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eblake at redhat dot com

--- Comment #13 from Eric Blake <eblake at redhat dot com> ---
(In reply to Paul Eggert from comment #12)
> It's not a POSIX violation if the shell executes "./a.out <&-" with stdin
> being closed. Although the command is not portable as-is and POSIX allows
> the shell to act as if the command were "./a.out </dev/null", POSIX doesn't
> require the shell to do so. Common shells close stdin (which POSIX also
> allows) and GNU utilities should do the right thing in this case. This
> action by common shells is what caused coreutils Bug#25029.

POSIX explicitly states that starting an executable with fd 0, 1, or 2 closed
puts the behavior of that executable outside the bounds of POSIX (that is, it
is undefined behavior to attempt to run "./a.out <&-", so POSIX no longer has
any say, and all bets are off).  So I definitely agree that this is not a
conformance issue, at least for freopen(stdin).

> 
> For what it's worth, I changed Gnulib to work around the glibc freopen
> behavior, which is unexpected by so many uses of freopen that I think it
> qualifies as a bug even if it's not a POSIX-conformance issue. This should
> fix the coreutils bug. Non-Gnulib-using applications are still vulnerable to
> the glibc problem.

Indeed, quality of implementation demands that we tolerate closed fds during
freopen(), since we already go out of our way to tolerate closed fds during
popen(), which is yet another place where POSIX has no direct say.

-- 
You are receiving this mail because:
You are on the CC list for the bug.