Date: Wed, 2 May 2007 18:59:28 -0500 (CDT) From: "Sean C. Farley" <sean-freebsd@farley.org> To: Daniel Eischen <deischen@freebsd.org> Cc: arch@freebsd.org Subject: Re: HEADS DOWN Message-ID: <20070502183100.P1317@baba.farley.org> In-Reply-To: <Pine.GSO.4.64.0705021332020.8590@sea.ntplx.net> References: <20070501083009.GA4627@nagual.pp.ru> <20070501160645.GA9333@nagual.pp.ru> <20070501135439.B36275@thor.farley.org> <20070502.102822.-957833022.imp@bsdimp.com> <Pine.GSO.4.64.0705021332020.8590@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 May 2007, Daniel Eischen wrote:
> On Wed, 2 May 2007, M. Warner Losh wrote:
>
>> In message: <20070501135439.B36275@thor.farley.org>
>> "Sean C. Farley" <sean-freebsd@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@farley.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070502183100.P1317>