setenv problems

[Jeff Johnston]

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