HEADS DOWN

Sean C. Farley sean-freebsd at farley.org
Thu May 3 00:26:21 UTC 2007


On Wed, 2 May 2007, Daniel Eischen wrote:

> On Wed, 2 May 2007, M. Warner Losh wrote:
>
>> In message: <20070501135439.B36275 at thor.farley.org>
>>            "Sean C. Farley" <sean-freebsd at farley.org> writes:
>> 
>> Questions for developers to help me proceed:
>> 1. Would POSIX or BSD be preferred?  By POSIX, I do not necessarily
>>    mean completely POSIX.  It can be some shade of gray.  For
>>    example, I added some checking to putenv() that is not mentioned
>>    in the POSIX spec but makes it closer to setenv() in its errors.
>
> POSIX is preferred unless there are good reasons to deviate
> from it for specific interfaces.  We are always free to add
> non-POSIX functions for functionality not defined by the
> standard.

That is good to know.  See below for notes about the divergence I made
from POSIX.

>> 2. Would a series of stages to move from BSD to POSIX be
>>    acceptable/desired?  This is to avoid POSIX from overwhelming
>>    people.
>> 3. How about dropping putenv() altogether?  :)  putenv() is ugly.
>>    My changes currently prevent setenv() from leaking like a sieve,
>>    so the need for putenv() should not be as necessary.  It could
>>    also be that shade of gray where putenv() stayed the way it is
>>    (wrapper around setenv()) while the rest can be POSIX.
>
> putenv() is in POSIX.  It should definitely be implemented.

Here[1] is my POSIX version of the *env() (including putenv())
functions.  It also has the leak-avoidance change that occurs with
setenv("ab") -> setenv("a") -> setenv("ab").  It is also faster than the
current code.

Where it diverges from POSIX:
1. putenv() sets errno to EINVAL since it performs checks (NULL pointer,
    empty string and string without '=') on the string given to it.  It
    makes it a bit more like setenv() in its validation.  I found this
    note[2] that says that providing invalid data to putenv() will result
    in undefined behavior.  I thought that undefined could mean an error
    is returned.  The check is easy to remove.
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.

Sean
   1. http://www.farley.org/freebsd/tmp/setenv-8/POSIX/
   2. http://www.opengroup.org/austin/mailarchives/ag/msg09682.html
-- 
sean-freebsd at farley.org


More information about the freebsd-arch mailing list