[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: getenv vs. locale

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.


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

Thank you.
I will remove the reference implementation for Scheme48.

On Thu, Jul 24, 2008 at 10:42 PM, Ivan Shmakov <ivan@xxxxxxxxxxxxx> wrote:
>>>>>> 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:
> --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.
> [...]