On Sat, 30 Aug 2003 15:08:23 +0100, Geoff Clare wrote:
>I think that to resolve this we need to ask the C Standard folks about
>the reasons behind this addition in the C Standard. At the moment I
>don't have any feeling for how they intended it to work, or how it
>is meant to be used. I also have questions about what the exact
>requirements of the C Standard on freopen(NULL, ...) are.
I sent your request to a member of the US "ANSI" C group that
understands I/O better than I. Here is his response:
> 1. Was freopen(NULL, ...) added to the C Standard in order to provide
> applications with a way of completely re-initialising a stream without
> needing to know the file name? Or is the whole point just the mode
> change, with other effects considered secondary?
The primary purpose was the mode change (particularly for the standard
streams that are automatically opened, quite possibly in the wrong
mode). Other effects are secondary.
> 2. Was the new feature based on an existing implementation? If so,
> what kind of implementation is it - in particular does it have
> something like a POSIX file descriptor underlying stdio streams?
> If it has an underlying fd, does freopen(NULL, ...) change the
> properties of the fd?
I don't recall any existing practice, just a clear need (in some
environments).
[freopen text elided]
> 3. Is the "as if" here intended to encompass properties of stdio streams
> beyond those specified in the C Standard?
Although that's beyond the scope of the standard, I would say that it
was intended to encompass all properties of the stream.
> [In POSIX we might want to say that the access mode of the underlying
> fd need not change, or that the FD_CLOEXEC flag is retained, but we
> can't do that if it would conflict with the requirements of the
> C Standard. I'm also wondering what implications this has for file
> types other than plain files, e.g. for a FIFO open for writing should
> another process reading the FIFO get EOF, for a connected socket
> should the connection be dropped?]
Since those things are out of scope for the C standard, I don't see any
conflicts. I think the POSIX folks need to decide what makes sense in
their environment. And since POSIX doesn't distinguish between text and
binary streams (does it?), always failing might be the most sensible
thing to do.
> 4. What happens if freopen(NULL, ...) is called with the same mode
> that the stream already has? Strictly speaking this is not a "change"
> of mode, so when the standard says "It is implementation-defined which
> changes of mode are permitted (if any), and under what circumstances",
> it is not clear how this applies to calls with the same mode.
I would say that it's technically a change of mode, even if the new mode
happens to be the same as the old mode. (Just like assigning a value to
a variable modifies it, even if the new value happens to be the same as
the old value.)
> 5. What is the required behaviour when a mode change that is not
> permitted by the implementation is attempted? Must the freopen() call
> return NULL, or is the behaviour undefined?
"The freopen function returns a null pointer if the open operation
fails."
---
Fred J. Tydeman Tydeman Consulting
yyyyyyy@xxxxxxxxx Programming, testing, numerics
+1 (775) 287-5904 Vice-chair of J11 (ANSI "C")
Sample C99+FPCE tests: ftp://jump.net/pub/tybor/
Savers sleep well, investors eat well, spenders work forever.
|