Tue Sep 23 16:06:00 GMT 2008
It is not directly stated on the getenv() page at opengroup.org but is
in the section on environment variables that '=' is not to appear in
an environment variable name.
> These strings have the form /name/=/value/; /name/s shall not contain
> the character '='. For values to be portable across systems conforming
> to IEEE Std 1003.1-2001, the value shall be composed of characters
> from the portable character set (except NUL and as indicated below).
> There is no meaning associated with the order of strings in the
> environment. If more than one string in a process' environment has the
> same /name/, the consequences are undefined.
I don't see any requirement on what getenv() should
do if the name string contains an equal. The case where
the first character is '=' could just as easily be interpreted
as an empty name string and thus an error.
As far as I can tell the behavior is undefined.
Pawel Veselov wrote:
> while looking through the cegcc project, I discovered a few issues
> with the setenv() (_setenv_r) and getenv() (_getenv_r) functions:
> 1. In the beginning of the function, the pointer to the value string
> is shifted if the string starts with '='. The comment says that is to
> prevent values to start from '='. I couldn't find anywhere in the
> definition of setenv() that a value may not start with equal
> character. Any reason for eating first equal character up?
> 2. The setenv() man pages seem to ask for returning EINVAL in case
> there is an equal character inside the name of the variable. It also
> says that glibc versions do allow to have environment variable names
> with equal signs in them, however, the current implementation of
> environment variables in newlib doesn't seem to be able to distinguish
> between those. (So, if you set variable named (a=b) with value (c),
> the getenv for (a) will return (b=c)). So I believe newlibs setenv
> should return EINVAL.
> 3. The getenv() implementation searches for the variables that have
> the name as passed, unless the name contains an equal sign in it, in
> which case, the only part that is searched for is the characters
> before the equal sign. So if you call setenv("foo", "bar", 1) and then
> call getenv("foo=grape"), you will get "foo=bar" as the result of that
> getenv call.
> Since cegcc project uses newlib for base library support, I'm
> cross-posting to both lists. Would appreciate any comments on the
> above. I can produce a patch that restricts both functions to POSIX
> With best of best regards
> Pawel S. Veselov
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the Newlib