Programs fail to execute with a runtime error when locale is set. The following codes fail both for english and greek (haven't checked with other locales) with the run-time error: "terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Aborted". The codes that fail: 1. #include <iostream> #include <locale> #include <string> int main() { using namespace std; locale::global(locale("en_US")); wcin.imbue(locale("greek")); wcout.imbue(locale("greek")); wstring ws; wcin>> ws; wcout<< ws<< endl; } 2. #include <iostream> #include <locale> #include <string> int main() { using namespace std; ios_base::sync_with_stdio(false); wcin.imbue(locale("greek")); wcout.imbue(locale("greek")); wstring ws; wcin>> ws; wcout<< ws<< endl; } 3. #include <iostream> #include <locale> #include <string> int main() { using namespace std; wcin.imbue(locale("greek")); wcout.imbue(locale("greek")); wstring ws; wcin>> ws; wcout<< ws<< endl; } It fails for files too: 4. #include <locale> #include <string> #include <fstream> int main() { using namespace std; wstring ws= L"Test"; wofstream file("filename.txt"); file.imbue(locale("greek")); if(file.is_open()) file<< ws; } The bug is serious, I can't save unicode texts in my programs!
Created attachment 16424 [details] The produced .ii file from code (2.) The produced .ii file from code (2.) compiled with the options: g++ -ansi -pedantic-errors -Wall -save-temps temp.cpp -o temp
Target? Named locales are supported *only* on GNU/Linux systems.
*** This bug has been marked as a duplicate of 32254 ***
(In reply to comment #2) > Target? Named locales are supported *only* on GNU/Linux systems. Ubuntu 8.04 x86. I am learning the QT package, and for example its QString provides a toStdString() function that returns a std::string and a toStdWString() function that returns a std::wstring. The specific member function I have the problem: void MainWindow::saveFile() { using namespace std; QString fileName= QFileDialog::getSaveFileName(this, tr("Save file"), tr(""), tr("Text files (*.txt)")); if(!fileName.isEmpty()) { string cFileName= fileName.toStdString(); wofstream cFile(cFileName.c_str()); if(cFile.is_open()) { QString text= textEdit->toPlainText(); wstring writtenText= text.toStdWString(); cFile<< writtenText; } else QMessageBox::critical(this, "Unable to save file!", "The file could not be created!", QMessageBox::Close); } } My system *is* GNU/Linux. Apart from that, why "named locales are supported only on GNU/Linux systems"? MINGW doesn't accept them for example? In any case, my problem is in a GNU/Linux system.
Given the problem you are reporting, the issue is definitely that either the GNU locale model has not been selected at build time, or the localedata is not available, please refer to 32254, for example, or many similar PRs of this type. Otherwise, the type of snippet which you are reporting about is daily tested multiple times by all the developers, many variants in the testsuite. As regards the generic locale model, we would not be able to guarantee multithread safety, but improvements are in principle welcome, just send over patches. Thanks. *** This bug has been marked as a duplicate of 32254 *** *** This bug has been marked as a duplicate of 32254 ***
The bug reports you are mentioning combined with 35353 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353), means that the locales implementation of GCC is a mess. I think the proper solution is to fix the locale problem, not trying to ignore it.
Thanks for your nice, encouraging words. We don't need duplicate reports, thanks. *** This bug has been marked as a duplicate of 32254 ***
Note: Change the encoding of your browser and email client to Greek-ISO or Unicode, so as to see the messages correctly. locale -a displays the following: john@john-desktop:~/Desktop/download/extract$ locale -a C el_CY.utf8 el_GR.utf8 en_AU.utf8 en_BW.utf8 en_CA.utf8 en_DK.utf8 en_GB.utf8 en_HK.utf8 en_IE.utf8 en_IN en_NZ.utf8 en_PH.utf8 en_SG.utf8 en_US.utf8 en_ZA.utf8 en_ZW.utf8 POSIX john@john-desktop:~/Desktop/download/extract$ ==> Using these locales in the 3 of the 4 codes supplied, they work OK. However the code number (3.) works only for "en_US.utf8", and it doesn't work for "el_GR.utf8". For "en_US.utf8": #include <iostream> #include <locale> #include <string> int main() { using namespace std; wcin.imbue(locale("en_US.utf8")); wcout.imbue(locale("en_US.utf8")); wstring ws; wcin>> ws; wcout<< ws<< endl; } john@john-desktop:~/Desktop/download/extract$ ./main Test Test john@john-desktop:~/Desktop/download/extract$ For: "el_GR.utf8" #include <iostream> #include <locale> #include <string> int main() { using namespace std; wcin.imbue(locale("el_GR.utf8")); wcout.imbue(locale("el_GR.utf8")); wstring ws; wcin>> ws; wcout<< ws<< endl; } john@john-desktop:~/Desktop/download/extract$ ./main Δοκιμαστικό john@john-desktop:~/Desktop/download/extract$ As I said, the locales work in the 3 of the 4 codes supplied, but code number (3.) doesn't. So this isn't a "blocker" bug, but there is still a bug with wcin.imbue() and wcout.imbue() when they are used alone without a "locale::global(locale("en_US"));" or "ios_base::sync_with_stdio(false);" statement. wofstream works OK without any of the above statements. For example the code: #include <locale> #include <string> #include <fstream> int main() { using namespace std; wstring ws= L"Δοκιμαστικό\n"; wofstream file("filename.txt"); file.imbue(locale("el_GR.utf8")); if(file.is_open()) file<< ws; } works OK: john@john-desktop:~/Desktop/download/extract$ g++ -ansi -pedantic-errors -Wall main.cpp -o main john@john-desktop:~/Desktop/download/extract$ cat filename.txt Δοκιμαστικό john@john-desktop:~/Desktop/download/extract$
(In reply to comment #8) > So this isn't a "blocker" bug, but there is still a bug with wcin.imbue() and > wcout.imbue() when they are used alone without a > > "locale::global(locale("en_US"));" > > or > > "ios_base::sync_with_stdio(false);" and this is clearly a duplicate of libstdc++/35353, which, note, given the current wording of the standard, is a Quality of Implementation Issue, not a proper bug. Anyway, as I said, nothing new here. *** This bug has been marked as a duplicate of 35353 ***