Re: C99 freopen

[Roland McGrath <roland at frob dot com>]

> Roland McGrath <roland@frob.com> writes:
> > That is not a reasonable approach.  I don't have the C99 spec so as to read
> > what its intent is supposed to be--but I find it hard to believe they
> > intended POSIX systems to introduce the one place where you can expect to
> > have the effect of determining a file name from a file descriptor (which in
> > the general case cannot be done).  The only thing that seems reasonable to
> > me is that this is expected only to work in the common case where
> > stdin/stdout/stderr are all copied from the same original descriptor on the
> > tty, that having been opened O_RDWR.  So, freopen's semantics would roughly
> > match those of fdopen(fileno(stream), newmode)--which is to say that
> > freopen can do the fcntl(F_GETFL) check on the requested new mode and tweak
> > the stream state to match the requested new mode, but that is all.
> 
> You must see this is the ISO C world which has no file descriptors.

ISO C was defined in the context of the world we live in, where the
prototypical underlying implementation is POSIX.  If the ISO C committee
nowadays is populated by people who are so foolish as to think the standard
can mandate wholly new functionality requiring deep changes in the ways
that underlying systems have worked for decades, then this so-called
"standard" is not one worth our attention.

> In general we don't need the file descriptor to file name mapping.  We
> can simply remember the file name provided at fopen() time (note that
> fdopen() is no ISO C function).  We can do this and support
> freopen(NULL) more widely but for Linux etc where we can determine the
> file name from the desriptor we should continue to do this since it
> would allow to handle the fdopen() case as well.

This approach is deeply wrong.  The name by which the file was opened at
some time in the past has nothing whatsoever to do with the file to which
an open stream refers.  To provide a half-assed implementation along these
lines gives the false impression that there is well-defined functionality
being provided despite the inherent impossibility of such on the underlying
systems we have.  Any programmer would be very foolish to write a program
that expected such behavior.

Can someone please cite for us the actual ISO C specification and rationale
text for this new behavior of freopen?  I am tired of arguing in the dark.
It is obvious to anyone who has been involved in the C and POSIX world for
any length of time that the only conceivable uses of this new addition that
a reasonable C standard would contemplate are those that correspond on
POSIX systems to reuse of the existing file descriptor.