Hi Andy,
On 07/13/11 01:48, Andy Wingo wrote:
I'm not sure what the bug report here is. I'm getting a lot of angst
though :-)
:) Not angst so much as mild irritation, some of it stirred up residuals
from the 1.4 -> 1.6 -> 1.8 transitions. I was only just recently able
to drop Guile 1.4 support and it will be a couple more before 1.6 goes
away. My feint hopes of getting rid of the versioned Guile glue layer
are now dashed:
On Mon 11 Jul 2011 15:28, Bruce Korb<[email protected]> writes:
The intent is that I have several functions: raw-shell-str, shell-str,
c-string and kr-string each of which produces precisely the same byte
sequence as their argument for the intended target environment.
But if I understand you correctly, here you would like to manipulate
*byte sequences* as strings. Strings are logically character sequences,
so you need to choose a mapping that preserves the identity of bytes
with characters. That mapping is latin-1.
"latin1" is an alias for "ascii byte strings"? Anyway:
In the NEWS for 2.0.0:
** New procedures: `scm_to_stringn', `scm_from_stringn'
** New procedures: scm_{to,from}_{utf8,latin1}_symbol{n,}
** New procedures: scm_{to,from}_{utf8,utf32,latin1}_string{n,}
These new procedures convert to and from string representations in
particular encodings.
Users should continue to use locale encoding for user input, user
output, or interacting with the C library.
This means that *THE SEMANTICS HAVE CHANGED* for these functions.
New semantics should always imply a new interface name.
This is a new interface.
Use the Latin-1 functions for ASCII, and for literals in source code.
The latin-1 functions should be the preferred spelling for the old "locale"
functions. The new locale functions need a new spelling. It is confusing
to have old functions performing new tricks. The old name needs a
compatibility grace period.
It sounds like you want scm_{to,from}_latin1_string. On Guile 1.8 and
before, you can #define this to scm_{to,from}_locale_string, as earlier
versions of Guile did not have the needed string encoding support.
Actually, I said what I meant. I want byte array functions where Guile
isn't thinking that it knows better than I do what bit values ought to
be in each byte. It is an array of byte values each of which is in the
range of 1 through 255 with the last value is always zero (0).
Thank you. Regards, Bruce
