Re: SCM_STRING_CHARS is deprecated. See the manual for alternatives.

[Bruce Korb]

Neil Jerram wrote:
> Bruce Korb <address@hidden> writes:
> > Here's the deal:  I just want access to the array of characters.
> OK, for this you should use scm_to_locale_string().

Which allocates and copies, leaving the free() to me.
At least I get what I have to have.  I did not find  it 'cuz
I was looking for "scm_c_*" procedures.  *sigh*.  I already
made a release using "scm_i_string_chars()", though, since
I stumbled across it investigating how SCM_CHARS(), er,
I mean SCM_STRING_CHARS() works.  I am sure you don't like
that, but in the end scm_to_locale_string() did not pop out
and I needed to use something.  I've put macro wrappers
around every single Guile function and versioned them all,
based on Guile version.  It changes too much.

I still wish you would add scm_c_eval_string_from_file_line().
That interface is stable, but the guts are ifdef-ed based on
Guile version.

> But please note that the main reason for the new API is the need to
> handle character encoding, in particular future Unicode support.  See
> the "Conversion to/from C" node in the manual for a bit more on this.

In my particular open source app, I mostly deal with byte arrays
terminated with a NUL byte.  I am a little unclear on the implied
intent, after reading that section.  I certainly hope it is not
your intention to change Guile to try to understand the contents
of these byte arrays.  Instead, I would expect and hope that you
would create a new family of functions that might, say, contain
the word "unicode" to imply that they work with unicode strings
instead of byte strings.  So, I will use "string" functions to work
with NUL terminated arrays of bytes, and "stringn" functions to
work with known-length, unterminated arrays of bytes.  I will
switch to "unicode" functions where appropriate and when available.
Please do not do that under the covers.  Thank you.

Regards, Bruce