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