[arch-general] Including compiled C.UTF-8 locale by default in glibc package? Inbox

[Neven Sajko]

On Wed, 16 Feb 2022 at 14:18, Greg Minshall via arch-general
<arch-general at lists.archlinux.org> wrote:
>
> Marius,
>
> > This mail just reminded me that one of my own projects didn't handle a messed
> > locale setup gracefully in the past causing multiple users (that apparently
> > had a messed setup) to report issues, e.g. https://aur.archlinux.org/packages/
> > syncthingtray#comment-816671 and https://github.com/Martchus/syncthingtray/
> > issues/109. And when I searched for the error to investigate the issue I found
> > many results. If it helps preventing applications from crashing completely
> > with errors like "locale::facet::_S_create_c_locale name not valid" it is
> > likely worth including.
>
> fwiw, for people writing code: a friend suggested something like this:
> first try user's configured locale (environment variables).  if that
> fails, try the "C" locale.  if that also fails, print out a warning, and
> continue to run:
> ----
>     /* modified from https://www.cl.cam.ac.uk/~mgk25/unicode.html */
>     if (!setlocale(LC_CTYPE, "") &&
>         !setlocale(LC_CTYPE, "C")) {
>         fprintf(stderr, "Warning: Can't set the specified locale! "
>                 "Check LANG, LC_CTYPE, LC_ALL.\n");
>         /* but, keep going */
>     }
> ----
> (though, of course, "continue to run" may not work in your case, i.e.,
> Boost or other frameworks, etc.)
>
> cheers, Greg

A C program is in the "C" locale already when it reaches the main
function, so I think there's no point to calling it again.

But I definitely agree that to crash or to refuse to run depending on
the locale is a serious bug.

Neven