Re: [Bug-autogen] test failure with guile-2.0.2

[Bruce Korb]

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<address@hidden>  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