|
Home > Archive > Unix Programming > April 2006 > putenv() error returns?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
putenv() error returns?
|
|
| Henry Townsend 2006-04-02, 7:42 pm |
| I find it interesting that both SUSv3 and the Solaris man page say of
putenv() that 'the argument should point to a string of the form
"name=value"', but in looking at the ERRORS section the only defined
error is ENOMEM "Insufficient memory was available". So what is putenv
supposed to do with a string that's ill-formed, whether by having no "="
sign or too many? And does this also mean that no restrictions are made
(at the putenv level) on the form of either 'name' or 'value', such that
I could create an EV whose name is composed of non-printable characters?
Of course I could try this on my platform (Solaris) and see what
happens. The question is more around standards and portability.
Thanks,
HT
| |
| Fletcher Glenn 2006-04-02, 7:42 pm |
| Henry Townsend wrote:
> I find it interesting that both SUSv3 and the Solaris man page say of
> putenv() that 'the argument should point to a string of the form
> "name=value"', but in looking at the ERRORS section the only defined
> error is ENOMEM "Insufficient memory was available". So what is putenv
> supposed to do with a string that's ill-formed, whether by having no "="
> sign or too many? And does this also mean that no restrictions are made
> (at the putenv level) on the form of either 'name' or 'value', such that
> I could create an EV whose name is composed of non-printable characters?
>
> Of course I could try this on my platform (Solaris) and see what
> happens. The question is more around standards and portability.
>
> Thanks,
> HT
Actually, putenv() could care less about the string contents. However,
you would only get good results from getenv() and other programs if
you follow the required format. A string that is not null-terminated
will give you undefined results any time that the string is accessed,
and I presume that it might cause problems when putenv() attempts to
copy the string into the environment. I doubt that putenv() does any
kind of fitness test on the submitted string.
--
Fletcher Glenn
| |
| Casper H.S. Dik 2006-04-02, 7:42 pm |
| Fletcher Glenn <fletcher@removethisfoglight.com> writes:
>Actually, putenv() could care less about the string contents. However,
>you would only get good results from getenv() and other programs if
>you follow the required format. A string that is not null-terminated
>will give you undefined results any time that the string is accessed,
>and I presume that it might cause problems when putenv() attempts to
>copy the string into the environment. I doubt that putenv() does any
>kind of fitness test on the submitted string.
Nothing, indeed; evironment "variables" are just strings and there
does not even need to be one "=". And multple "=" signs
are perfectly OK and sometimes needed,
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Jordan Abel 2006-04-02, 7:42 pm |
| On 2006-03-27, Casper H.S Dik <Casper.Dik@Sun.COM> wrote:
> Fletcher Glenn <fletcher@removethisfoglight.com> writes:
>
>
>
> Nothing, indeed; evironment "variables" are just strings and there
> does not even need to be one "=". And multple "=" signs
> are perfectly OK and sometimes needed,
Except that getenv and many other ways of accessing them depend on the
first '=' being present.
| |
| Barry Margolin 2006-04-02, 7:42 pm |
| In article <slrne2gi89.1jtf.random832@random.yi.org>,
Jordan Abel <random832@gmail.com> wrote:
> On 2006-03-27, Casper H.S Dik <Casper.Dik@Sun.COM> wrote:
>
> Except that getenv and many other ways of accessing them depend on the
> first '=' being present.
But there's no requirement that you use getenv to access them. You can
access the environ array directly and forget about getenv and friends.
You can think of the "=" as analogous to the "-" at the beginning of
command line options. If you use getopts() then you must follow the
standard option convention, but if you parse the command line yourself
you can do whatever you like. The same goes for processing the
environment array -- if you use standard functions you have to follow
the standard style, but you can roll your own and do what you want.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Henry Townsend 2006-04-02, 7:42 pm |
| Barry Margolin wrote:
> You can think of the "=" as analogous to the "-" at the beginning of
> command line options. If you use getopts() then you must follow the
> standard option convention, but if you parse the command line yourself
> you can do whatever you like. The same goes for processing the
> environment array -- if you use standard functions you have to follow
> the standard style, but you can roll your own and do what you want.
Good analogy. The difference, however, being that the environment is
inherited by unsuspecting child processes while a command line is not.
HT
| |
| Jordan Abel 2006-04-02, 7:42 pm |
| On 2006-03-28, Barry Margolin <barmar@alum.mit.edu> wrote:
> In article <slrne2gi89.1jtf.random832@random.yi.org>,
> Jordan Abel <random832@gmail.com> wrote:
>
>
> But there's no requirement that you use getenv to access them. You can
> access the environ array directly and forget about getenv and friends.
Yes, but MANY ways of accessing the environment depend on the = sign
"convention" - implementations may be permitted to represent them
differently internally [i suppose, then, accesses into environ will
fault and the system will allocate the appropriate strings]
|
|
|
|
|