freopen_safer

[Eric Blake]

I just discovered a problem with freopen when one of the std streams are 
closed; this affects the behavior of coreutils' mktemp(1).

So far, I have tested cygwin and Solaris 8, which both change the underlying fd 
of a stream passed to freopen.  Looking at the source code of glibc, it looks 
like the same thing will happen there, although I still need to test that.  If 
one of the standard streams starts life closed, this means the use of freopen 
silently! breaks invariants that STDERR_FILENO == fileno(stderr).

$ cat foo.c
#include <stdio.h>
int main()
{
  if (stderr != freopen("/dev/null","w",stderr))
    return 5;
  return fileno(stderr);
}
$ ./foo && echo $?
2
$ ./foo <&- && echo $?
0
$ ./foo >&- && echo $?
1

This should definitely be fixed for clients of the stdio-safer module (and its 
corresponding "stdio--.h") - if we ever violate the premise that 
STDERR_FILENO==fileno(stderr), then the whole point of the *_safer functions is 
lost.  But I'm wondering if the behavior of changing to a lower fd during 
freopen is universal across all platforms, or whether there are existing libc 
where freopen guarantees the reuse of the original fd even if open() would have 
picked a lower fd.  In that case, we could argue that platforms that don't 
reuse the same fd during freopen should blindly use rpl_freopen, even when the 
stdio-safer module is not in effect.

-- 
Eric Blake