Re: setenv problems

["Pawel Veselov" <pawel dot veselov at gmail dot com>]

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.

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