Subject: Re: Re: C99 questions about freopen(NULL, ...)
--------
> Geoff Clare said:
> > 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.
> >
> > First the questions about the background for the addition:
> >
> > 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 mode change.
>
> > I'm thinking that
> > maybe the idea is that an application which opens a file read-write to
> > write some data that it will then read back could change the mode to
> > read-only after it has written the data. Is that the kind of use that
> > was envisaged, or something else?
>
> Actually, where this started was with the question:
>
> How do I write cat(1), or cpio(1), or ..., in Standard C?
>
> More precisely, if a program is required to read standard input or write
> standard output in binary mode, how does the programmer do this, since thos
> streams will initially have opened in text mode.
>
> At the same time, we realized that some changes would not be possible.
> Hence the wording.
>
> > 2. Was the new feature based on an existing implementation?
>
> Not that I recall.
I have heard that this was based on sfio which has this feature.
It only allows mode changes when consistent with the underlying
file or memory stream. It does not reopen the underlying file.
>
> > Now about the requirements of the C Standard. As a reminder the text
> > in question is:
> >
> > "If filename is a null pointer, the freopen function attempts to
> > change the mode of the stream to that specified by mode, as if the
> > name of the file currently associated with the stream had been
> > used. It is implementation-defined which changes of mode are
> > permitted (if any), and under what circumstances."
> >
> > 3. Is the "as if" here intended to encompass properties of stdio streams
> > beyond those specified in the C Standard?
>
> I don't believe we intended to specify that in either way, no.
>
> > 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.
> > One possible interpretation is that because freopen() "attempts to
> > change the mode", when the same mode is requested it cannot "change"
> > the mode, so the call must fail.
>
> On the contrary, I would say this is an automatic success. But I could
> accept that this is also a case that the implementation can define either
> way.
>
> > 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 former.
>
> --
> Clive D.W. Feather | Work: <yyyyy@xxxxxxxxx> | Tel: +44 20 8495 6138
> Internet Expert | Home: <yyyyy@xxxxxxxxxx> | *** NOTE CHANGE ***
> Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051 9937
> Thus plc | | Mobile: +44 7973 377646
>
>
David Korn
yyy@xxxxxxxxxxxxxxxx
|