Ever since I've been hacking on pspp, we've been using printf et al for data-in/out functions. When we introduced i18n, this caused a problem, because printf is dependent upon the LC_NUMERIC locale category.
We avoided this problem, simply by setting all categories *except* LC_NUMERIC This seems to have worked until now (bug #37366). I cannot reproduce the problem - but I suspect it has to do with the later version of libc that Mindaugus is using. From the trials that Mindaugus has been doing I suspect, that the problem pertains to the thread safety (or lack thereof) with the setlocale function. It seems the black magic we've been using to set all locale categories except LC_NUMERIC is working only in certain threads. If I am right that this is a libc is the independent variable, then we can expect a lot of users to start complaining after their operating systems get upgraded. Mindaugus correctly points out that ignoring the LC_NUMERIC locale is not good anyway (it means that certain aspects of the GUI don't get displayed as users might want). So I think we need to fix the problem, not just the symptom. That is to say, we should set ALL locale categories, and deal with the consequences where, in the past we have relied upon the C locale behaviour. There are several approaches that I can think of: 1. Use write a set of c-printf functions. Unfortunately, there aren't any in gnulib. 2. Surround all the relavate *printf calls with setlocale calls to set the locale to C and back again afterwards. 3. I think the only locale pertinent thing is the decimal separator. Furthermore, I think I am correct, when I say that all locales use either '.' or ',' So we could deal with the printed strings dealing with an occurence of either as a decimal separator. 4. Can we start using the newlocale function ? Other suggestions? J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://keys.gnupg.net or any PGP keyserver for public key.
signature.asc
Description: Digital signature
_______________________________________________ pspp-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/pspp-dev
