[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: getenv vs. locale
>>>>> higepon <higepon@xxxxxxxxx> 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:
; 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
; 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.
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,
> Fortunately, your suggestion (c) is not inconsistent with simple one,
> we can leave some rare cases to another srfi.