Post #3081692

Replies (1)

• @mirabilos@toot.mirbsd.org 2026-04-24 05:17

  @uecker@mastodon.social hmm, seems like a weak pro. This will change programs that currently (correctly) assume the C locale on startup, e.g. is(w)alpha may change. More troublesome is that blank, cntrl and space on the currentl practical C.UTF-8 implementations differ from C (in the one in MirBSD they didn’t, but I’ll be aligning that to what (e)glibc does). I have, in fact, gotten bugreports for things like tr -dc '[[:alpha:]]' not DTRT due to over-eager UTF-8ification. That’s why I believe that the current “call setlocale(LC_ALL, ""); near the beginning of main to opt in to having locales other than C” is the correct thing to keep. If you take POSIX into account, the C locale is always 8bit, so you can use the wide and multibyte functions like the narrow ones (though the numerical mapping is not guaranteed, of course). The C.UTF-8 locale, on the other hand, usually does not work for all possible input octet combinations (even if it does, this really needs a change to mbrtowc to work (return value 0 can also signify state being used up, check *pwc == 0 instead) and a mapping of octets that aren’t well-formed UTF-8 to a special transport encoding, like I do in MirBSD). I’ve also seen editors suddenly truncate files, after they have been locale-enabled. This will cause bugs.

  Open ##3081693