HEADS DOWN

[Daniel Eischen]

On Wed, 2 May 2007, Sean C. Farley wrote:

> On Wed, 2 May 2007, Daniel Eischen wrote:
>
>> On Wed, 2 May 2007, Sean C. Farley wrote:
>
> <snip>
>
>>> 2. getenv() sets errno to EINVAL and returns NULL if given a bad name
>>>    to find.  setenv() and unsetenv() perform the same check on the
>>>    name; should not getenv() do the same?  The check is easy to
>>>    remove.
>> 
>> I don't think getenv() should set errno.  The fact that it
>> returns NULL is sufficient and POSIX doesn't define any errors
>> for it.
>
> Fixed for errno.  Also, no value is appropriate for errno when the name
> does not exist.  How about the feature that getenv() returns a NULL for
> a bad name instead of allowing a core dump?  Is that acceptable?

I thought that is what I said above ;-)  POSIX says this about getenv():

   Upon successful completion, getenv() shall return a pointer to a string
   containing the value for the specified name. If the specified name cannot be
   found in the environment of the calling process, a null pointer shall be
   returned.

I'd argue that a bad name is the same thing as if it were a good name
but couldn't be found.  You really don't want a core dump unless you
have to jump through too many hoops to prevent one.  As long as the
name is a valid pointer to a valid string, then you should just
search the environment for the string.  It looks like the only character
not allowed is '='.

-- 
DE