SCM_STRING_CHARS is deprecated. See the manual for alternatives.

SCM_STRING_CHARS is deprecated. See the manual for alternatives.

[Bruce Korb]

Hi,

Um.  I did.  This is all I find:

 -- Macro: char * SCM_STRING_CHARS (SCM X)
 -- Macro: char * SCM_SYMBOL_CHARS (SCM X)
     Return a pointer to the characters of X.  The result is undefined
     if X is not a symbol or string, respectively.

   There are also a few magic values stuffed into memory before a
symbol's characters, but you don't want to know about those.  What
cruft!

   Note that `SCM_VECTOR_BASE', `SCM_STRING_CHARS' and
`SCM_SYMBOL_CHARS' return pointers to data within the respective
object.  Care must be taken that the object is not garbage collected
while that data is still being accessed.  This is the same as for a
smob, *Note Remembering During Operations::.

==================================

* SCM_STRING_CHARS:                      Vector Data.         (line  36)



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Neil Jerram]

Bruce Korb <bkorb@gnu.org> writes:

> Hi,
>
> Um.  I did.  This is all I find: [...]

There are a load of new functions beginning with "scm_c_string" and
"scm_to_locale_", which you can find in the manual index.  Can you
take a look at these and see if they help?

Regards,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Kevin Ryde]

Bruce Korb <bkorb@gnu.org> writes:
>
>   There are also a few magic values stuffed into memory before a
> symbol's characters, but you don't want to know about those.  What
> cruft!

That para sounds a bit unnecessary, doesn't it :).

>   Note that `SCM_VECTOR_BASE', `SCM_STRING_CHARS' and
> `SCM_SYMBOL_CHARS' return pointers to data within the respective
> object.  Care must be taken that the object is not garbage collected
> while that data is still being accessed.  This is the same as for a
> smob, *Note Remembering During Operations::.

Not sure if that's true any more either.  Is the "remembering"
protection enough now?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

SCM_STRING_CHARS is deprecated. See the manual for alternatives.

[Bruce Korb]

Hi,

I've seen the manual.  For Guile 1.8 it says:

>  -- Macro: char * SCM_STRING_CHARS (SCM X)
>  -- Macro: char * SCM_SYMBOL_CHARS (SCM X)
>      Return a pointer to the characters of X.  The result is undefined
>      if X is not a symbol or string, respectively.
>
>    There are also a few magic values stuffed into memory before a
> symbol's characters, but you don't want to know about those.  What
> cruft!
>
>    Note that `SCM_VECTOR_BASE', `SCM_STRING_CHARS' and
> `SCM_SYMBOL_CHARS' return pointers to data within the respective
> object.  Care must be taken that the object is not garbage collected
> while that data is still being accessed.  This is the same as for a
> smob, *Note Remembering During Operations::.


Here's the deal:  I just want access to the array of characters.
I've never presumed the characters are NUL terminated.  Now,
I am getting this message and the code itself says:

> static SCM
> make_stringbuf (size_t len)
> {
>   /* XXX - for the benefit of SCM_STRING_CHARS, SCM_SYMBOL_CHARS and
>      scm_i_symbol_chars, all stringbufs are null-terminated.  Once
>      SCM_STRING_CHARS and SCM_SYMBOL_CHARS are removed and the code
>      has been changed for scm_i_symbol_chars, this null-termination
>      can be dropped.
>   */

Unfortunately, it seems to take a lot of grubbing around in the
source code to find out how to do this.  I am completely aware of
the fact that any call to any Guile function can invalidate an
address gotten via this mechanism.  However, with a single threaded
program and without making such a call, I know the address will
remain valid.  I want it.  It saves a lot of allocate, copy & free
bother.  Thank you!  Regards, bruce


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Neil Jerram]

Bruce Korb <bkorb@gnu.org> writes:

> Here's the deal:  I just want access to the array of characters.

OK, for this you should use scm_to_locale_string().

>  I am completely aware of
> the fact that any call to any Guile function can invalidate an
> address gotten via this mechanism.  However, with a single threaded
> program and without making such a call, I know the address will
> remain valid.  I want it.  It saves a lot of allocate, copy & free
> bother.  Thank you!  Regards, bruce

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.

Regards,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Bruce Korb]

Neil Jerram wrote:
> Bruce Korb <bkorb@gnu.org> 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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel