5 ms·

I guess we should all just force-set our C programs to the C locale.

• rwmj 8y ago
  In all the scripted tests we write, one of the first lines will be: export LANG=C A similar construct is also used in most places where we call sort (except where we're actually sorting strings of text that will be read by an end user), eg: <some source of data> | LANG=C sort
  • jwilk 8y ago
    Setting LANG=C is not sufficient, because LANG can be overridden by various LC_* variables. You should set LC_ALL=C instead.
    • usr1106 8y ago
      LC_COLLATE is the critical category according to the bug report. No need to set anything else.
      • jwilk 8y ago
        It's not enough if LC_ALL is already set in environment, sice that would override LC_COLLATE. So just set LC_ALL and be done with it. It's bulletproof.
• patrec 8y ago
  This works till you want at least minimal UTF-8 support, such as when you're working with actual English text as opposed to human-readable computerese.
  • kazinator 8y ago
    Sticking to the "C" locale will work even if you want UTF-8 support. You just roll your own UTF-8 support. I built the TXR language entirely without any of the harmful garbage that is the ISO C/POSIX localization. It handles UTF-8 just fine. The C localization stuff was developed too early, at a time when nobody had any real experience with localization. Before Unicode, before the Internet. Before threads! How the do you set it up so that one thread runs in one locale and another in another? That's important if a global server is servicing two different requests simultaneously from users in two different locales. The idiotic C locale stuff relies on global variables. You set some magic variables and, poof; numerous functions in your entire image change their behavior, whether they are working with internationalized data or not. The setlocale function might as well be called fuck_my_program_please.
• kazinator 8y ago
  > I guess we should all just force-set our C programs to the C locale. Ah, but you are in luck: this is not required! A C program begins execution in the "C" locale, regardless of the environment variables. The locale variables do not affect a C program until it calls the "fuck this program function" called setlocale, with LC_ALL, and "". The empty string argument means "use the environment variable". The problem is that many modern utilities in GNU/Linux land all make this setlocale call, in order to support internationalization. So then they are affected by whatever hell breaks loose. Your own program is safe, if neither it, nor a third party library, calls setlocale, then your strcmp and isalpha and whatever else behave in good old naive manner.