Putting out a floating point value seems to change the global C locale. Just compile and run the attached test program and you'll see that the last call to isalpha returns false instead of the expected true. If you comment out the line that outputs the fp value, isalpha returns true as expected. 3.3.1 and 3.3.2 also have the same bug that I consider quite nasty and unexpected.
Created attachment 5027 [details] Testcase that shows the libstdc++ bug
Hi, I can reproduce it and construct a pure "C" testcase in this sense: in v3 we use glibc uselocale assuming the the semantics is such that the below outputs 0, 1024, 0, 1024 *not* 0, 1024, 0, 0 !! #define _GNU_SOURCE 1 #include <locale.h> #include <stdio.h> int main() { __locale_t loc_new, loc_old; printf("%d\n", isalpha(0xE4)); // 0 setlocale ( LC_ALL, "de_DE" ); printf("%d\n", isalpha(0xE4)); // 1024 loc_new = newlocale(1 << LC_ALL, "C", 0); loc_old = uselocale(loc_new); printf("%d\n", isalpha(0xE4)); // 0 uselocale(loc_old); printf("%d\n", isalpha(0xE4)); // 0 *not* 1024! freelocale(loc_new); return 0; } What are we doing wrong?? Why the (global) de_DE locale is not restored for the current thread by the second uselocale? I hope to sort this out before leaving to Nuremberg! Paolo.
Another observation: actually, only the behavior of isalpha changes (and probably that of all the other functions provided also in the *_l version by glibc2.3.*) whereas the thread local locale is properly restored to de_DE after the formatted output: try a sequence of 3 printf("%f\n", 1.2) instead and you will notice that the third one, correctly (as prescribed by the de_DE locale, that is) prints the decimal separator as a comma, not as a dot!
Hi again. I have got this reply from Roland McGrath (glibc maintainer): >No confusion, just a bug. I've fixed it. The bug affected ctype functions >after uselocale (LC_GLOBAL_LOCALE), but not other uses of locale data. > > >Thanks, >Roland So, indeed, it's a glibc bug. Unfortunately, it will not be publically corrected 'til glibc2.3.3, I'm afraid, and I don't think is in our policy putting in workarounds, in such cases... I'm open to suggestions, however! Paolo.
If we get floating point printing in place that doesn't rely on sprintf anymore, this issue should disappear for float output. Mucking with the global locale is only necessary to ensure correct sprintf behavior.
*** Bug 14970 has been marked as a duplicate of this bug. ***
I guess we can close this one: 17140 tracks the specific issue with new floating point output code.