Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!ltuxa!we53!wucs!wucec2!jdz
From: jdz@wucec2.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Unix standard output buffer problem
Message-ID: <1474@wucec2.UUCP>
Date: Wed, 12-Mar-86 17:11:12 EST
Article-I.D.: wucec2.1474
Posted: Wed Mar 12 17:11:12 1986
Date-Received: Fri, 14-Mar-86 05:28:20 EST
References: <1421@brl-smoke.ARPA> <203@dg_rtp.UUCP>
Reply-To: jdz@wucec2.UUCP (Jason D. Zions)
Organization: Wash. U. Center for Engineering Computing
Lines: 27

In article <203@dg_rtp.UUCP> throopw@dg_rtp.UUCP writes:
>To answer your question directly, there is *no* *way* to do what you
>said you wanted to do.  Altering an address space before an exec had
>*better* *not* have any effect on the address space seen after the exec,
>or exec just isn't doing it's job.  The only way to alter the address
>space gotten by execing an executable image is to patch the image on
>disk (or link a new one).

Well, on machines that implement ptrace(3) or some equivalent/variant,
one can start-up the child to be traced, poke the new bits in, and then
let it run. Yeah, I know, slow, ugly, unportable, etc.

But not impossible.

I wouldn't recommend it, for most of the reasons mentioned above. But if you
have to have it, there you go. I shudder at the thought of poking around
the namelist of the child executable to find the appropriate virtual address
of the particular word to be poked... And it will never work on stripped
images (for this reason). Yuck!

The beauty of Un*x is that almost nothing is impossible. The biggest drawback
to Un*x is that those "impossible elsewhere" functions are UGLY!!!!!
-- 
Jason D. Zions			...!{seismo,cbosgd,ihnp4}!wucs!wucec2!jdz
Box 1045 Washington University
St. Louis MO 63130  USA		(314) 889-6160
Nope, I didn't say nothing. Just random noise.