Message-Id: <200110021518.LAA17354@qnx.com>
Subject: Re: putenv question
To: djgpp-workers AT delorie DOT com
Date: Tue, 2 Oct 2001 11:18:42 -0400 (EDT)
From: "Alain Magloire" <alain AT qnx DOT com>
In-Reply-To: <3BB9C9AA.7B4E13BF@inti.gov.ar> from "salvador" at Oct 02, 2001 11:05:31 AM
X-Mailer: ELM [version 2.5 PL0b1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> 
> Tim Van Holder wrote:
> 
> > On Tue, 2001-10-02 at 05:39, Charles Sandmann wrote:
> > > I don't have a posix standard, so a simple question ...
> > >
> > > putenv in 2.03 took a const char * argument
> > >
> > > When it was moved to the posix section in cvs it is no longer const
> > > When I passed the const strings "lfn=" in mntent I had to unconst
> > > the strings to avoid warnings.  Is it against the standard or some
> > > other way bad for this to be const in the headers?  Just wondering.
> >
> > Since the POSIX draft standard listed putenv's argument as a non-const
> > char*, I changed our implementation to match (and added a note about
> > this to wc204.txi).
> > I don't really see why it can't be const, but I felt it would be best to
> > follow the standard.
> 
> Perhaps is related to the fact that not all implementations makes a copy (as
> djgpp does) and hence a const could generate problems.

To add to what "SET" is saying:

Implementation should not make a copy of the string because this will
violate the standard,  (but I may be wrong 8-).

int putenv (char *string);

In either case, the "string" becomes part of the environment, so
altering the string shall change the environment.

So making a copy will no reflect any changes.
and saying putenv (const char *) will not convey the right information
to the user.

> What is supposed to return getenv() according to the standard? is it a char
> *?

Yes.

> The djgpp's help clearly states the behavior of putenv and warns about what
> other implementations does, but I felt victim of a stupid bug anyways:
> 
> void function()
> {
>  char buffer[xx];
>  strcpy(buffer,...);
>  putenv(buffer);
> }
> 
> ;-)
> Of course it generates really bizarre things with GNU libc (which doesn't
> copy the string).

8-)
Yes, you would be in big ... if you do another call to putenv() or getenv()
since the stack will be unwind.

The problem with this API, is that it is easy to have a memory leak,
if you do not keep track of things.

putenv (strdup ("HOME=/home/alain");
putenv (strdup ("HOME=/home/richard");
putenv (strdup ("HOME=/home/eli");
putenv (strdup ("HOME=/home/robert");
putenv (strdup ("HOME=/home/set");

But you can not do free (getenv ("HOME")); either since
it may point to static data or thing you should not free() 8)
Cool hey!


In many implemetation environ is just
char *environ[];

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!