Bogus putenv?

Jeff Johnston jjohnstn@redhat.com
Wed Nov 24 15:03:00 GMT 2004


Ralf Corsepius wrote:
> 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.
>

Actually, I'm not sure what I was thinking when I wrote that. :(  The const is 
just assuring that the function isn't modifying the input string, which it 
shouldn't and doesn't.

> 
>>  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.
> 

I should have supplied the context:

Online SUSv2 says:

"The putenv() function makes the value of the environment variable name equal to 
value by altering an existing variable or creating a new one. In either case, 
the string pointed to by string becomes part of the environment, so altering the 
string will change the environment. The space used by string is no longer used 
once a new string-defining name is passed to putenv(). "

I interpret the last line as meaning that once you use another string to modify 
the environment variable, the old string is no longer capable of changing the 
environment directly for that value.  The new string gets that capability.

I was trying to note that this is not true for newlib's current implementation 
where we are making a copy of the string.

The same functionality is described by glibc.  Not sure why they wouldn't have 
specified const, but regardless, we might as well be consistent with Single Unix 
and glibc.  I will change this.

-- Jeff J.



More information about the Newlib mailing list