[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strings/chars

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 14:46:08 -0500

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

I only meant that such "simplest" FFI have to leave the behavior
undefined when the Scheme string has wider range of characters.
It is simple to provide such FFI on most implementations.
It is just not clear to me that it is simple to write a portable,
reliable code with the FFI.

I'm not opposing your idea; I merely want to make the implication
of your suggestion explicit.

NB: if portability of the FFI code isn't an issue, defining FFI
as it returns 'const char*' in implementation-specific encodings
except the C execution character set, is perfectly valid.
C code writers would know how the implementation behaves.
And that's not worse than the current situation of Scheme world
(w.r.t large character set) anyway.