Adding putenv/setenv functionality to libiberty (for fixincl)

[Melissa O'Neill]

Bruce Korb <ddsinc09@ix.netcom.com> asked me to forward this message
(because netcom is on the ORBS blacklist).  I've edited his text slightly,
for clarity of attribution and to summarize quoted material that was
starting to lose its context.

			BTW, ORBS is now also blocking the mail server
			for my department, because it found a machine on a
			dial-up line that had an open relay and our mail
			server trusts the dial up lines.  Thankfully,
			I have other mail servers I can use for now, but
			I fear the same problem get them onto ORBS too.
			If I vanish, you'll know why.

Message-ID: <01BEAAB7.7F352900@sa-207-251-8-126.cruzio.com>
From: Bruce Korb <ddsinc09@ix.netcom.com>
To: "'Melissa O'Neill'" <oneill@cs.sfu.ca>
Subject: RE: Adding putenv/setenv functionality to libiberty (for fixincl)
Date: Sun, 30 May 1999 16:14:22 -0700

Melissa O'Neill wrote:
>> My feeling here is that I have unearthed a portability issue in fixincl.

... and Jeff Law replied:
> Agreed.

Agreed again, tho I have not seen your message.

> And thus we have 3 solutions:
>
>  1. Always use putenv from libiberty, using the semantics provided by
>     libiberty (not as easy as it might sound since putenv is only included
>     in libiberty if it's not in the system C library).

Not as difficult as it might sound, since there are trivial methods for
forcing setenv/putenv to go into the library.

>  2. Avoid putenv entirely.  Possibly settling on setenv if it has better
>     defined semantics.

This is was what I said a while ago.

>  3. Support both variants of putenv (yuk).

Bzzt.  :-)

> I'd lean towards #2.  It seems the safest assuming that the behavior of
> setenv hasn't changed over time.

I think I would insist on it, partly just because you would be guaranteed
that it comes from libiberty (wouldn't you?  It is not listed in any of my
handy man pages for SVR1, BSD4.2 and SVR5.)

>> [After writing a test program, I observe that Solaris, SunOS and
>>  SYSVR4 machines have a putenv that aliases, and Linux machines have
>>  a putenv that copies (strcpy or equivalent). I'm pretty sure that
>>  BSD variants with putenv also copy.]
>
> On 4.4bsd (and likely its derivatives) putenv copies.

I wonder, do you suppose it would be better to just get the address of
the environment pointer array and insert my own pointer into it?

Ah, there is one other possibility.  Currently, the shell script for
fixing a header is static.  (This is the only context within which this
putenv/setenv stuff is used anyway!)  I could, instead, do the following:

    static const char z_shell_fix[] = "file='%s'\n%s\n";
    sprintf( z_shell_buf, z_shell_fix, pz_file, p_fix->pz_script );

and then use z_shell_buf to the execl("sh", "-c", z_shell_buf) call.
Now, we can dump the setenv/putenv entirely  :-))
I would have to distinguish shell invocations from sed
invocations, however :(.  That, however, ought to be much easier
than all this other horsing around!!

Regards,
	Bruce