Re: setenv problems

[Jeff Johnston <jjohnstn at redhat dot com>]

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