X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 98A8F3858C36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1695323260; bh=/Ipi2U4qQsKkELLwtphboc5PCV8o++19sYmclPYQ/ks=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=yZcT4TxCmMKIZSPX4ejuLCdDGS8Xd/HznewzP0gzrGl59S2BYnu+46OP/hTowRv5k gxLOQDXA5AQxdKOIx29T2T3d/5tP5mvkPnxLPZ3gx/3onliBupi4/kXAkVX79o9eeT IEZENSlTBOcrqGBaSxcybc7bY4jzpK1objsS86bE= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E93593858D39 Subject: Re: std::runtime_error on std::locale("") To: cygwin AT cygwin DOT com References: <20230922011204 DOT bb166498090e6cbe163349f3 AT nifty DOT ne DOT jp> <20230922012856 DOT 47872090281f2a303fd7b99f AT nifty DOT ne DOT jp> <0fab8831-c206-14fe-4350-3092e62fca98 AT Shaw DOT ca> Message-ID: <07777266-f285-be52-0bff-752419352e85@t-online.de> Date: Thu, 21 Sep 2023 21:06:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 SeaMonkey/2.53.16 MIME-Version: 1.0 In-Reply-To: <0fab8831-c206-14fe-4350-3092e62fca98@Shaw.ca> X-TOI-EXPURGATEID: 150726::1695323220-38C76192-41927D51/0/0 CLEAN NORMAL X-TOI-MSGID: 57e66ba0-9af7-4ac8-bba8-50b4cc4b15e5 X-Spam-Status: No, score=3.1 required=5.0 tests=BAYES_00, BODY_8BITS, FREEMAIL_FROM, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Christian Franke via Cygwin Reply-To: Christian Franke Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 38LJ7fxG011107 Brian Inglis via Cygwin wrote: > On 2023-09-21 10:28, Takashi Yano via Cygwin wrote: >> On Fri, 22 Sep 2023 01:12:04 +0900 >> Takashi Yano wrote: >>> I wonder why the following code throws std::runtime_error >>> even though the LC_ALL is set to valid locale other than "C". >>> This does not occur only when LC_ALL is set to "C". >>> >>> #include >>> int main() >>> { >>>     std::locale(""); >>>     return 0; >>> } >>> >>> In linux, this occurs only when the LC_ALL is set to invalid >>> locale (i.e. locale that is not registered in system). >> >> Similarly, >> std::locale("ja_JP.UTF-8") >> throws std::runtime_error in cygwin. > > Looks like the implementation does not like any default "" or explicit > "en_US.UTF-8" strings there! See example at link and below; results > are always the same: > >     https://en.cppreference.com/w/cpp/locale/locale > > #include > #include > > int main() > { >     std::wcout << "User-preferred locale setting is " >            << std::locale().name().c_str() << '\n'; > >     // on startup, the global locale is the "C" locale >     std::wcout << 1000.01 << '\n'; > >     // replace the C++ global locale and the "C" locale with the > user-preferred locale >     std::locale::global(std::locale("")); >     // use the new global locale for future wide character output >     std::wcout.imbue(std::locale()); > >     // output the same number again >     std::wcout << 1000.01 << '\n'; > } > > $ g++ -o c++locale{,.cc} > $ ./c++locale > User-preferred locale setting is C > 1000.01 > terminate called after throwing an instance of 'std::runtime_error' >   what():  locale::facet::_S_create_c_locale name not valid > Aborted (core dumped) > According to libstdc++ source, the internal function locale::facet::_S_create_c_locale() calls some __newlocale() which apparently does not arrive at newlocale() from cygwin1.dll. But cygstdc++-6.dll imports newlocale() from cygwin1.dll. Only standard locale "C" and its alias "POSIX" work with C++ std::locale(). The cygwin1.dll function newlocale() works as expected - except that it does not set errno if the locale name is invalid. -- Regards, Christian -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple