>From: higepon <xxxxxx@gmail.com>
Subject: Re: getenv vs. locale
Date: Sun, 20 Jul 2008 21:33:54 +0900

> Thank you for your suggestions.
>
> > (a) Raises an exception (natural, but may be inconvenient in some cases)
> > (b) Returns some value indicating such condition has happened
> > (c) Allow an optional 'filter' argument.
>
> I think (a) is good.
> It is enough for my usage (CGI applications).
>
> What cases are inconvenient?
> Procedures return raw value(s) are necessary?

Initially I thought it would be cumbersome to wrap every
occurrence of getenv if I wanted to make sure getenv won't
stop an application.  But maybe it's not so bad, since giving a
proper filter argument is probably equally cumbersome.  And
in either way, you can't change the behavior of getenvs used
within third-party libraries.  So, the advantage of (c) is
greater flexibility, including the integration of raw value
handling into getenv function.
(Alternatively, the condition thrown by getenv may include
the offending value in it.)

Do we need raw value handling?  Well, maybe.  I tend to say
yes because of my tendency to try to cover all possible cases,
but am not sure its practical implication.  Besides the
obvious use cases such as logging and fancy error reporting,
what I can think of is contrived examples such as
the value of PWD includes a multibyte directory name whose
encoding is different from the process's locale and you
might want to convert it implicitly.

The option (c) is difficult to implement on top of the
existing implementations, in most of which getenv is a primitive
procedure returning a string (but there's the same difficulty
in the option (a) if you want to define a specific condition
getenv should throw).

Ultimately, the choice depends on the purpose of this srfi.
If this one just wants to summarize "current practices", leave
the behavior undefined and cross your fingers that it works
"most of the time".  If this one wants to provide a portable
and robust basis, specify the behavior and encourage existing
implementations to follow.  I tend to vote the latter.
(It would be very annoying if my application calling
get-environment-variables keeps failing on the user's machine
but not on my machine, and finding out it's because a single
value in some obscure environment variable.)

--shiro