On Sun, 27 May 2001, Xavier Hienne wrote:
> Is it intended to (somehow) duplicate stdout ? If so, why not merely use
> dup(2) ?
Yes, I have tried this and it does work... the question is whether this:
> The problem here is that fclose() causes a close()
> of the underlying fd (stdout).
...happens only on some C libraries, or on all. Maybe I'm being silly
but my POSIX book does not mention whether the underlying fd is closed;
glibc's manpage says it is. However if the POSIX specification is vague,
different UNIX implementations could conceivably not close it and leak
descriptors. My book says exactly this: "any system resources that were
automatically allocated are deallocated" but when the stream comes from
fdopen, the fd is *not* automatically allocated. The glibc manpage may
say that the fd is closed, but it starts with the somewhat fishy description:
"The fclose function dissociates the named stream from its underlying
file or set of functions" which may be a rip from earlier C manpages
and seems to infer that the intent is to sever the association, not
necessarily destroy the fd.
If I am being silly (which happens quite often :-) then I'll just add
the dup (that's the way I have it in my working tree right now) but if
not, I will have to check when the fclose is called to see if the file
descriptors are still valid afterward, and if so, close them, in
order to be portable.
--
Brian
