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.
From: Jim Blandy <jimb@xxxxxxxxxx> 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