Email list hosting service & mailing list manager


Re: Strings/chars Shiro Kawai 08 Jan 2004 21:59 UTC

>From: Jim Blandy <xxxxxx@redhat.com>
Subject: Re: Strings/chars
Date: 08 Jan 2004 14:46:08 -0500

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

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.

--shiro