Well, I've read the manual about scm_*_locale_string. It shows: ----------------------------------- Note that these functions should not be used to convert C string constants, because there is no guarantee that the current locale will match that of the source code. To convert C string constants, use scm_from_latin1_string, scm_from_utf8_string or scm_from_utf32_string. ------------------------------------
I think there's in a dilemma. According to the manual, we should convert string or change locale in the users' code. But Guile will break in (command-line) proc, because Chinese string as command arguments can not get valid result from "u32_conv_from_encoding" called by "scm_from_stringn", and raised an error. So we don't have any chance to convert it or change locale from environment in the users' code because Guile has already crashed by "decoding-error". Now I have two questons: 1. Maybe we raised this "decoding-error" too early. Can we let "scm_from_locale_stringn" just return the string which wasn't recognized as a bytevector? Then we may convert it as wish. But it's confused for "scm_from_locale_stringn" returning a bytevector; 2. Why not let "scm_from_locale_stringn" return string according to the locale from current environment as my patch?
