Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Newsgroups: comp.os.linux.development.apps
Subject: Re: How to dup a FILE*
Date: Wed, 07 Dec 2011 17:52:18 +0000
Lines: 61
Message-ID: <8762hs6zhp.fsf@sapphire.mobileactivedefense.com>
References: <jbkl2v$a75$1@nntp.ts.fujitsu.com> <20111206195333.49dd7a9d@dwnoon.ntlworld.com> <8762hto2p4.fsf@sapphire.mobileactivedefense.com> <20111206214641.3265e741@dwnoon.ntlworld.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: individual.net o/L5B6h4iRG42Y6zNvUPpAr3bxrGpKBXhD8598NQOGNH44KGQ=
Cancel-Lock: sha1:l2LyrAMTx2Cy7/vJa5Razni3yUI= sha1:ftXNX16E38wh/AO3BATaUWIawpw=
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Xref: x330-a1.tempe.blueboxinc.net comp.os.linux.development.apps:304

David W Noon <dwnoon@spamtrap.ntlworld.com> writes:
> On Tue, 06 Dec 2011 20:38:47 +0000, Rainer Weikusat wrote about Re: How
> to dup a FILE*:

[...]

>>> I think you're over-complicating things here.  After all, stderr is
>>> simply a pointer.  So, cache the old pointer; open a new file stream
>>> stored in stderr; fclose(stderr) when done; reinstate the original
>>> pointer.
>>
>>That's a thoroughly stupid idea because it won't affect output to
>>'standard error filedescriptor' which doesn't go through the stderr
>>stream *and* while the glibc documentation claims that this should
>>work, it actually doesn't (or at least didn't for some random version
>>where I tried this about ten years ago -- only to be told that I
>>"should use freopen instead" by Ulrich Drepper [which I couldn't do
>>because I was trying to divert the output to a socket]).
>
> The C Standard Library does not provide "file descriptors" with any
> specified meaning, only as opaque integers.

The 'C standard library' doesn't provide file descriptors at all. On
systems supporting the UNIX(*) API, 'file descriptor' is usually an
abstraction provided by the kernel.

> Consequently, all error logging *should* be done using the stderr
> stream, not fd of 2. It is only a happenstance of platform-specific
> shells and run-time libraries (e.g. glibc) that stderr defaults to
> fd of 2 on UNIX-like systems.

	The <unistd.h> header shall define the following symbolic
	constants for file streams:

	STDERR_FILENO
	    File number of stderr; 2.
	STDIN_FILENO
	    File number of stdin; 0.
	STDOUT_FILENO
	    File number of stdout; 1.

	[http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html]

Also,

	The <stdio.h> header shall define the following macros which
	shall expand to expressions of type "pointer to FILE" that
	point to the FILE objects associated, respectively, with the
	standard error, input, and output streams:

	stderr
	    Standard error output stream.
	stdin
	    Standard input stream.
	stdout
	    Standard output stream.

	[http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdio.h.html]

Note that this say 'expression' and not 'modifiable lvalue' as the
errno definition does.