As described in BZ#21398 (close as dup of 21393) report current
freopen implementation fails when one tries to freopen STDIN_FILENO,
STDOUT_FILENO, or STDERR_FILENO. Although on bug report the
discussion leads to argue if a close followed by a freopen on the
standard file is a valid operation, the underlying issue is not
really the check for dup3 returned value, but rather calling it
if the returned file descriptor is equal as the input one.
So for a quality of implementation this patch avoid calling dup3
for the aforementioned case. It also adds a dup3 error case check
for the two possible failures, with one being Linux only: EINTR and
EBUSY. The EBUSY issue is better explained on this stackoverflow
thread [1], but in a short it is due the internal Linux
implementation which allows a race condition window for dup2 due
the logic dissociation of file descriptor allocation and actual
VFS 'install' operation. For both outliers failures all allocated
memory is freed and a NULL FILE* is returned.
With this patch the example on BZ#21398 is now actually possible
(I used as the testcase for the bug report). Checked on
x86_64-linux-gnu.
[BZ #21393]
* libio/freopen.c (freopen): Avoid dup already opened file descriptor
and add a check for dup3 failure.
* libio/freopen64.c (freopen64): Likewise.
* libio/tst-freopen.c (do_test): Rename to do_test_basic and use
libsupport.
(do_test_bz21398): New test.
* manual/stdio.texi (freopen): Add documentation of EBUSY failure.
[1] http://stackoverflow.com/questions/23440216/race-condition-when-using-dup2
f1a67a2c78