Shiro Kawai <xxxxxx@lava.net> writes:
> 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.

Well, if the *only* behavior the FFI offered were to provide text in
the C execution character set, then that would limit portability.  But
I only meant to suggest that that be the simplest way to do things.
Providing additional entry points for retrieving text in some fixed
encoding is still a good idea, as it was when it was first proposed.

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

I think Gtk+ / Pango / etc. require UTF-8 strings, no?  And Windows
uses wide characters holding Unicode code points.  So those would be
good things to have.