Newsgroups: comp.unix.internals
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!stanford.edu!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Subject: Re: Redirection of stderr
Organization: Lawrence Berkeley Laboratory, Berkeley
References: <574@dprmpt.UUCP> <521@bria> <524@bria> <11127@dog.ee.lbl.gov> <536@bria>
Message-ID: <11319@dog.ee.lbl.gov>
X-Local-Date: Fri, 22 Mar 91 01:03:51 PST
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Date: Fri, 22 Mar 91 09:03:50 GMT
Distribution: na

>>In article <524@bria> uunet!bria!mike writes:
>>>#define fdup2(A,B)	(memcpy(B,A,sizeof(FILE)))	/* UGLY */

>In article <11127@dog.ee.lbl.gov> I wrote:
>>Not only that, it does not work---because there is no guarantee that
>>a FILE object holds the state. [...]

(Perhaps `does not' was too strong; but I wanted to scare people away....)

In article <536@bria> uunet!bria!mike writes:
>As I leap to my defense ...
>
>'Twould be true to state that it does not work for all implementations;
>works just swimmingly for me, though! :-)

Actually, it works under my stdio as well, and on most machines it is
sheer insanity to write one's stdio such that it will fail.  But it is
dangerous to assume that, because it works now, it will always work.
Code that uses an `fdup2' concept at all is probably best ported by
fixing the code, rather than making `fdup2' work.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov