This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
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.