This page is part of the web mail archives of SRFI 98 from before July 7th, 2015. The new archives for SRFI 98 contain all messages, not just those from before July 7th, 2015.
From: higepon <higepon@xxxxxxxxx> 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