Re: Crashes with non-default language environments

[Stefan Monnier]

>> Oh, that's right, we still don't have it.  We only have the 3 variants
>> on the uni->multi, but not on the multi->uni.
>> I guess now is a good time to introduce it.

> But, even if we implement string-to-unibyte, it should be
> used for a string containing only ascii and eight-bit chars.
> And in that case, string-make-unibyte behaves exactly the
> same as string-to-unibyte.

No it would be different: it would also signal an error if some
non-binary char is found.  (I might potentially be convinced that it's
OK to additionally accept the 128-255 latin1 chars as alternatives to
eight-bit chars, since they now get character codes 128-255).

> We now have
> `list-to-raw-string-whose-bytes-in-memory-should-have-exactly-the-same-values-as-the-elements-of-this-list';
> that is `unibyte-string'

Yes, thanks.  I didn't know about it.  It's a great addition (tho the
name might be a bit short for Miles's tastes, we may want to add
list-to-raw-string-whose-bytes-in-memory-should-have-exactly-the-same-values-as-the-elements-of-this-list'
as an alias for it ;-).


        Stefan