This is the mail archive of the newlib@sourceware.org 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


Pawel Veselov wrote:
On Mon, Sep 22, 2008 at 10:18 AM, Joel Sherrill
<joel.sherrill@oarcorp.com> wrote:
Hi,

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.
http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html
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.

http://www.opengroup.org/onlinepubs/000095399/functions/setenv.html says that setenv() should fail with EINVAL if name contains an equal sign.

Ok, also considering the linux man pages state the same and the function isn't specified by ANSI. Would you like to try your hand at a patch?

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

getenv() with the name that contains an equal sign would inadvertently fail by returning an empty string because no name can contain an equal sign, as there is no specification of an alternative behavior in such case, the string can be interpreted literally in all cases (at least it's allowed to). However, the only problem with getenv() that I found that it would succeed, in case it both contains an equal sign, and the character sequence before the equal sign contains a string that exists in the environment, which I believe is improper.

Regarding the "first character being an equal sign" issue, the only
problem with that is that for some reason setenv won't accept values
with such characters (well, it will accept them, but will eat up first
and only first equal sign).

As far as I can tell the behavior is undefined.

Jeff?

--joel

Pawel Veselov wrote:
Hi,

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

Thanks,
 Pawel.


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




Thanks,
Pawel.


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