>From: Jim Blandy <xxxxxx@redhat.com>
Subject: Re: Strings/chars
Date: 08 Jan 2004 03:09:58 -0500

> I think it's important to work well with C as it is, and not try to
> correct C's problems in the SRFI API.

I agree.

> The simplest and easiest ways to access Scheme strings' contents and
> Scheme characters should return the corresponding strings and
> characters in the C program's execution character set.  That is:
>
> - Extracting the first character of the Scheme string "z" had better
>   yield the C character 'z'.
>
> - I shouldn't have to mention any character set by name, or do any
>   kind of character set conversions at all, to write C code that
>   checks whether a given string's contents are "foo".

I understand your suggestion means "the FFI deals with the
underlying C implementation's execution character set;
if the Scheme string contains characters outside the C's
execution character set, the behavior is undefined."

It is a possible solution.  At least it's not worse than
programming in C anyway.  It does limit the "portability" of
the FFI (severely, IMHO), but like other issues, it's a tradeoff.

> Only after those two cases are covered should one move on to providing
> ways to reliably get UTF-8, UCS-4, or whatever you like.

There are lots of external libraries that require explicit
character encoding schemes (it's not my or your like, but they
require it).   If this FFI leaves the encoding issue as
Scheme-implementation dependent, this FFI can't be used portably
to bridge to those libraries.  (Again, it's a matter of how
we set the scope of the FFI).

--shiro