Thomas Seeling wrote in a message to Richard Illes:

 RI> code, Visual C zero's out the FILE pointer after a fclose() and any

 TS> I cannot imagine that. The prototype is "int fclose(FILE
 TS> *)", so how should it be possible to zero the pointer
 TS> itself? To do what you tell here, it would have to be
 TS> something like "int fclose(FILE **)".

The C language looks at streams, which are associated with FILE structs,
while the operating system looks at handles, which are usually of type int.
 As a practical matter, the C run-time library would keep the operating
system handle as a member of the FILE struct, and it is probably this which
is being zeroed out.  Ordinarily, the FILE struct should be treated by the
programmer as a black box provided by the C run-time library.

 RI> further fprintf() to this pointer causes nothing to happen..

 TS> fprintf(NULL,...) should cause an exception, not "nothing".

The pointer is probably valid, pointing at an deinitialized FILE struct
containing an invalid file handle.  Attempting to write to such a stream
would have undefined consequences, but might not cause any exception.  For
example, if the file handle happened to have been zeroed, then the effect
would be something like fprintf(stdin,...), which is valid but meaningless.

 RI> CSet just leaves the FILE pointer a mess which causes a trap on 
 RI> fprintf().

 TS> This is up to the compiler implementors.

No.  As you note, fclose() takes a pointer to FILE as an argument, and it
cannot modify the pointer itself.  What the writer means is that the FILE
struct pointed to is modified by fclose(), which is expected.
 
-- Mike


---