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

Neven,

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.

ah, thanks. i didn't know that. with the new "C.UTF-8", possibly it makes sense to try falling back to that locale (after "" fails), before defaulting to the "C" locale? cheers, Greg

Ralph,

Or worse, it may continue to run but cause corruption of data.

thanks for weighing in. i sympathize with (and find appealing) your position. but, i think this may be a trade-off between usability and correctness. (we more often talk about the trade-off between usability and security.) if so, there may be no "absolutely right" answer to how to deal with it. i think it used to be the case that many unix/linux users didn't have their locale stuff very straight. i don't know the extent to which that is still true. i think it reasonable to expect programmers to figure out how to do things, set things up, "right". (and, of course, that's what you're trying to suggest!). but, "end users" may be lost, and expecting them to do get things configured correctly before providing them service may be unrealistic. (a risk -- but, to the users? to us developers? --- is that they get so frustrated they give up.) and, in fact, the services themselves -- like sed(1) and grep(1) -- may be tools a user might need to use in order to figure things out. [*] my take would be, printing a stern warning to stderr is a reasonable compromise. but, ytmv, as it were. it was also very helpful for me in this exchange to learn that if the call to, e.g., `setlocale(LC_CTYPE, "")` fails, *that* is when the error message should appear. and, also the fact that "C" locale will "always" be there, so there's no reason to try doing a `setlocale()` to it as a fall back. my current code does try to fall back on `C.UTF-8`: ---- if (!setlocale(LC_CTYPE, "")) { fprintf(stderr, "Warning: Can't set the specified locale! " "Check LANG, LC_CTYPE, LC_ALL.\n"); #if defined(STOP_IF_NO_LOCALE) exit(RET_LOCALE); #else /* defined(STOP_IF_NO_LOCALE) */ /* make an attempt to activate C.UTF-8, if available, but * ignore any errors. */ setlocale(LC_CTYPE, "C.UTF-8"); #endif /* defined(STOP_IF_NO_LOCALE) */ } ---- cheers, Greg [*] fwiw, sed and grep both seem to run even if they are unable to deal with an unsupported locale. ps--

Looking at the URL, it doesn't suggest an attempt to fall back to the C locale.

Neither does the web page suggest the program continue, but instead exit with an error status.

sorry, the URL was acknowledging where i got the general structure; as The Author says, "Any remaining errors are, of course, my responsibility." :)