Hi Bruce, I'm not sure what the bug report here is. I'm getting a lot of angst though :-)
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. 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. Use the Latin-1 functions for ASCII, and for literals in source code. Use UTF-8 functions for interaction with modern libraries which deal in UTF-8, and UTF-32 for interaction with utf32-using libraries. Otherwise, use scm_to_stringn or scm_from_stringn with a specific encoding. See also http://www.gnu.org/software/guile/manual/html_node/Conversion-to_002ffrom-C.html. 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. Regards, Andy -- http://wingolog.org/
