[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Shiro Kawai <shiro@xxxxxxxx> 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.