Tue Nov 23 19:17:00 GMT 2004
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.
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
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
More information about the Newlib