This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug manual/670] system() documentation is incomplete (for standard streams)
- From: "vincent+libc at vinc17 dot org" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 18 Jan 2005 00:02:38 -0000
- Subject: [Bug manual/670] system() documentation is incomplete (for standard streams)
- References: <20050115212800.670.vincent+libc@vinc17.org>
- Reply-to: sourceware-bugzilla at sources dot redhat dot com
------- Additional Comments From vincent+libc at vinc17 dot org 2005-01-18 00:02 -------
A few notes that, I hope, will make things clearer:
* system() is a C function, not a system call. In C, one deals with files, not
file descriptors (well, at least not in a ISO C99 standard way). So, *from this
point of view*, a C implementation that would make the parent's and the child's
stdout files correspond to the same stream would be quite intuitive. My example
shows that the implementation provided by glibc is different. That's why I think
that it should be documented in some way.
* The behavior one can see in my example depends in fact on how freopen was
implemented. Internally, the freopen implementation could have chosen to reuse
the same file descriptor 1 (instead of taking the lowest free file descriptor).
Note that such internals are not documented in the glibc manual (at least under
the concerned functions). In fact, this is completely transparent as long as
only C functions (except system()) are used. But when system() is called, these
internal mechanisms are no longer transparent for the C programmer. So, even
though the "strange" behavior may initially come from the freopen() function,
something should be said about that under the system() function documentation.
* In my example, I did not close explicitly the file descriptor 1. This happened
only because of non-documented internal mechanisms, that should be regarded as
unknown for the C programmer who uses functions on files only (which is the case
in my example). This point of view makes the remarks on what happens with shell
redirections (that are based on file descriptors) off topic.
I'm reopening the bug for the above reasons (and because there haven't been
additional comments from others).
--
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
http://sources.redhat.com/bugzilla/show_bug.cgi?id=670
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.