>>>>> higepon  <xxxxxx@gmail.com> writes:

[...]

 >> 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.

 > Thank you for your kind explanation.  It was clear enough for me to
 > understand what you meant.

 > I want to summarize "current practices".  So I suggest for keeping it
 > simple we summarize "current practices" in this srfi.

	It should be noted that `lookup-environment-variable' returns a
	byte-vector-like object, namely, an ``OS string'', in Scheme48.
	Despite the issues were already noted on the list, I'd like to
	quote a related comment:

--cut: scheme48/scheme/rts/os-string.scm--
; You may think that file names / environment variables / user names
; etc. are just text, but on most platforms, that assumption is wrong:
; They are usually NUL-terminated byte strings in some format.  The
; bytes are invariant, but the corresponding text may depend on the
; locale.  Also, byte sequences without a textual representation are
; possible.

; We assume that OS strings are encoded in some conservative extension
; of NUL-terminated ASCII.  On Unix, this assumption pretty much has
; to hold true because of the various constraints of locale handling
; there.  The Windows API uses an extension of UTF-16 that includes
; unpaired surrogates.  For this, we use a synthetic extension of
; UTF-8 called UTF-8of16 that also deals with unpaired surrogates.
--cut: scheme48/scheme/rts/os-string.scm--

	It also means that the reference implementation given for
	Scheme48 is invalid (for Scheme48 after 1.3.)

	On the other hand, SLIB provides its `getenv' on top of
	`lookup-environment-variable' for both Scheme48 1.3 and higher,
	e. g.:

http://cvs.savannah.gnu.org/viewvc/*checkout*/slib/scheme48.init?root=slib

 > Fortunately, your suggestion (c) is not inconsistent with simple one,
 > we can leave some rare cases to another srfi.

[...]