>From: Ludovic Courtès <l...@gnu.org> >>Bruno Haible <br...@clisp.org> skribis: > >> No, I'm suggesting to let the Scheme code know that is it using the user's >> locale. >> >> Yes, this is a backward-incompatible change, so probably you won't want to >> do it on the guile 2.0.x branch, and you will want to advertise it in the >> release notes or NEWS file. > >I’m now convinced that an implicit setlocale(LC_ALL, "") is the right >thing for ‘master’. > >For 2.0, though, this brings us back to the hack I proposed at the >beginning of this thread, namely trying to honor LC_CTYPE without >actually calling setlocale, so that command-line arguments are suitably >converted.
I probably shouldn't express an opinion on this, since my SLOC count is so low these days, but, I'll do it anyway. ;-) As I am snarkily wont to say, everyone wants Unicode but no one really uses it. It you were to make that change in 2.0.x, I can almost guarantee that no one will be adversely affected. 2.0.x programs that are already trying to use locale will just have a redundant call to setlocale. 2.0.x programs that ignore locale are de facto C locale anyway. The scripts that would be at risk are those that try to read binary data as string input instead of binary input. Here's a suggestion. One could add an option to the guile interpreter's command line args (--locale=ARG perhaps) that has the effect of calling setlocale(LC_ALL,"ARG") first thing. If --locale is called with no ARG specified, it would call to setlocale(LC_ALL, ""). That way, people could start future-proofing their code now by adding --locale or --locale=C to the top of their scripts. For now, the default can be, in effect, --locale=C and for 2.2 it can be --locale. That would slightly complicate getopt processing, since you'd have to scan for the --locale before processing other getopt arguments. -Mike
