This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: setenv problems


It is not directly stated on the getenv() page at 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        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available             (256) 722-9985

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]