|
|
Clark S. Cox III wrote:
> kuyper@xxxxxxxxxx wrote:
> > Sjoerd Bakker wrote:
> >> On Fri, 13 Oct 2006 11:12:18 -0700, James Dennett <jdennett@xxxxxxx>
> >> wrote:
> >>
> >>> Sjoerd Bakker wrote:
> > ....
> >>>> fclose() can set the FILE * to a "magic" trap
> >>>> value the first time it is called to indicate that the pointer is
> >>>> invalid, and recognize the value a subsequent time it is called and
> >>>> return EOF.
> >>> No it cannot; it does not have access to the caller's
> >>> copy of the FILE*,
> >> You can't know that. It can be implementation-dependent.
> >
> > How can fclose() legally change the contents of an object defined in
> > user code that it hasn't been given a pointer to? Would you care to
> > identify the clause in the standard that makes it
> > implementation-dependent?
> >
> > If this applies to fclose(), doesn't it apply to every other standard
> > library function? If I write something like the following:
> >
> > #include <string.h>
> > int func(void)
> > {
> > int i=0, j=1, k=2;
> > memcpy(&i, &j, sizeof j);
> > return i*k;
> > }
> >
> > Do I have to worry about the possibility that memcpy() might change the
> > value of 'k'?
>
> No, you don't. fclose can't actually change the *representation* of the
> passed in FILE*. It can, however, cause that representation to become an
> invalid value (by free()'ing it for instance).
That's exactly what I've been saying. I was pointing out that what
fclose() can't do is fill the FILE* pointer whose value is passed to it
with what Sjoerd calls a "magic trap value". fclose() could put that
representation on a black-list, and fail safely (as he claims is
required) if called a second time with an argument which is on the
blacklist. But if it does so, if must guarantee that fopen() never
again produces a value from the blacklist. Since those values identify
the locations of FILE objects, that essentially means that those FILE
objects are unavailable for re-use. Many applications open only a few
files in their entire lifetime, so this wouldn't be a seruious burden
for them. However, applications which open and close thousands of files
in their lifetime are far from being uncommon, and would suffer serious
memory leaks from the use of such a strategy.
If fclose() were capable of changing the representation of the object
containing the pointer value which is passed to it, it could change it
to represent the same special value ( (FILE*)NULL seems a good
candidate) every time it is called. Then there's only be one special
value it would have to recognise, and fopen() would not be seriously
constrained by this requirement.
|
|