Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: notesfiles
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!hp-pcd!hpfcls!rml
From: rml@hpfcls.UUCP (rml)
Newsgroups: net.unix-wizards
Subject: Re: Orphaned Response
Message-ID: <132000010@hpfcls.UUCP>
Date: Wed, 15-May-85 19:31:00 EDT
Article-I.D.: hpfcls.132000010
Posted: Wed May 15 19:31:00 1985
Date-Received: Thu, 23-May-85 01:31:42 EDT
References: <-52100@nbs-amrf.UUCP>
Organization: Hewlett-Packard - Fort Collins, CO
Lines: 24
Nf-ID: #R:nbs-amrf:-52100:hpfcls:132000010:37777777600:1304
Nf-From: hpfcls!rml    May 17 15:31:00 1985

> Subject: Re: Setting environment variables within a C program.
> 
> I don't know the "right" way, but one way is to copy the environ array
> pointers into a new array and make your change.  The reason you have to
> use a new array is in case the change you are making adds a variable to
> the environment.  If you are only resetting a variable, you just
> reassign that one pointer to the variable value.  The reason this is
> kludgey, of course, is that the space from the original environ becomes
> unusable garbage.  That is, I haven't the faintest idea how to return
> it (i.e.  free) to useful life.

Why is it a problem to copy the original array?  You only need to copy
the pointers (not the environment strings themsleves).  Even with a
hundred 4-byte pointers, this wastes all of 404 bytes (with the null
terminator).  The problem becomes even less significant when the
environment is being modified in preparation for a call to exec(2).

In answer to your question, I don't know of a general-purpose, portable
way to either avoid the copy or re-use the space.  One
non-general-purpose way would be in a case where the program was able to
find an entry in the original environment which it knew to be useless;
it could replace that pointer with one to the new entry.

			Bob lenk (hpfcla!rml)