fclose(stdin);

[viza]

Hi!

Is there any harm/advantage to closing the standard input stream if I am not
going to read from it again?

I have:

if(blah)
fileptr=fopen(blah);
else
fileptr=stdin;

stuff;

if(fileptr!=stdin) /*this line*/
fclose(fileptr);

Can I just miss out the marked line and close whatever fileptr is?

Also, assuming I don't need the stream again, (and I can be reasonably sure
no other process will want it in the mean time) what reason is there to
close the file at all, as exit() will eventually close all open streams
anyway?

[Michael B Allen]

On Sat, 19 Jul 2003 15:45:17 -0400, viza wrote:

Hi!

Is there any harm/advantage to closing the standard input stream if I am
not going to read from it again?
There is no harm and there is an advantage if you would like your
program to use as little memory as possible or file handles are in high
demand. In certain environments it is standard practice to close stdin,
stderr, and stdout so that the program can run as a background process
without confusing the parent process from which the program was spawned.
Also, assuming I don't need the stream again, (and I can be reasonably
sure no other process will want it in the mean time) what reason is
there to close the file at all, as exit() will eventually close all open
streams anyway?

Because it's a memory leak. If your program is short lived and opens
only a few files then I suppose memory leaks are ok. But I never write
code like that (try not to) just on principle.

Mike

[those who know me have no need of my name]

in comp.lang.c i read:

On Sat, 19 Jul 2003 15:45:17 -0400, viza wrote:

Is there any harm/advantage to closing the standard input stream if I am
not going to read from it again?

There is no harm and there is an advantage if you would like your
program to use as little memory as possible or file handles are in high
demand. In certain environments it is standard practice to close stdin,
stderr, and stdout so that the program can run as a background process
without confusing the parent process from which the program was spawned.

actually this has subtle problems. an issue for a different group to
discuss.

--
a signature