Re: Bogus putenv?

[Ralf Corsepius <ralf_corsepius at rtems dot org>]

On Mon, 2004-11-22 at 14:07 -0500, Jeff Johnston wrote:
> Ralf Corsepius wrote:
> > Hi,
> > 
> > newlib's stdlib.h declares
> > int putenv( const char* );
> > 
> > According to SUSv3, Linux and Solaris, this should be (without const)
> > int putenv( char* );
> > 
> > FreeBSD, however has the same declaration as newlib (with const).
> > 
> > At least I am in favor of following SUSv3 and to ignore BSD's behaviour,
> > i.e. I vote for changing newlib's putenv to match with SUSv3.
> > 
> > Ralf
> > 
> > 
> 
> You have to take into account how putenv is implemented.  The reason putenv has 
> a non-const parameter for those situations is that those functions use the input 
> strings directly.

I am confused. IMO, the opposite is true. 

In my understanding, a "const *parameter" being passed to a function
implies the function being allowed to use the pointer directly, while a
"non-const * parameter" permits the application to modify the pointer.

>   Modification to the string after the call directly changes 
> the environment.

SUSv3 says:
...
int putenv(char *string);
...
The space used by string is no longer used once a new string which
defines name is passed to putenv().
...

IMO, this implies putenv to be supposed to make a local copy of
"string", therefore the case you are referring may not occur.

>   Newlib's implementation does not do this.  It makes a copy of 
> the string and passes it to setenv.  Modifying the input string does not affect 
> subsequent getenv calls for newlib.
>
> If you are willing to change putenv to work by using the strings directly, I am 
> ok with such a change.

I am still confused. What you describe as newlib's behavior (newlib
using a local copy of the string) matches with my understanding of
SUSv3.

In this case, I do not understand why newlib uses a "const char*", while
its putenv implementation (according to what you wrote above) doesn't
need it.

Ralf