From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5505 invoked from network); 1 Nov 2020 21:05:51 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Nov 2020 21:05:51 -0000 Received: (qmail 14319 invoked by uid 550); 1 Nov 2020 21:05:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 14293 invoked from network); 1 Nov 2020 21:05:44 -0000 Date: Sun, 1 Nov 2020 16:05:32 -0500 From: Rich Felker To: =?utf-8?B?w4lyaWNv?= Nogueira Cc: Szabolcs Nagy , musl@lists.openwall.com, Alexander Vitiuk Message-ID: <20201101210530.GP534@brightrain.aerifal.cx> References: <20201101204002.GA1370092@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] swprintf possible bug On Sun, Nov 01, 2020 at 05:48:43PM -0300, Érico Nogueira wrote: > On Sun Nov 1, 2020 at 6:40 PM -03, Szabolcs Nagy wrote: > > * Érico Nogueira [2020-11-01 17:17:49 -0300]: > > > On Sun Nov 1, 2020 at 6:06 PM -03, Alexander Vitiuk wrote: > > > > It seems, wsprintf() / wprintf() are not working in musl as expected, if > > > > uses with cyrillic: > > > > > > > > C testcase: > > > > #include > > > > int main() { > > > > wprintf(L"[hello]\n"); > > > > wprintf(L"[Привет]\n"); > > > > return 0; > > > > } > > > > on x86_64-linux-gnu prints: > > > > [hello] > > > > [Privet] > > > > and on x86_64-linux-musl prints: [hello] > > > > [ > > > > > > > > There are other cases described: > > > > https://github.com/emscripten-core/emscripten/issues/11947 > > > > > > For what it's worth, if this is a bug, it would seem to be in how musl > > > decides when to print characters (not the formatting functions > > > themselves), since the below program doesn't print anything: > > > > > > #include > > > #include > > > > > > int main() { > > > fputws(L"[Привет Василий]\n", stdout); > > > // I don't know if I'm accessing a wchar_t appropriately here > > > fputwc(L"[Привет Василий]\n"[3], stdout); > > > return 0; > > > } > > > > > > I tried tracing the execution from fputws, and not printing anything > > > seems to be caused by the return value of wcsrtombs(). > > > > these functions return an error code.. > > > > in this case they must return -1 and set errno to EILSEQ, > > since the selected multibyte encoding (LC_CTYPE=C) cannot > > represent the printed wide characters. > > > > i think the musl behaviour is correct, you can try adding > > setlocale(LC_CTYPE,"") at the start of main to make it work. > > Thanks, that did fix it. For reference: > > #include > #include > #include > > int main() { > setlocale(LC_CTYPE, ""); > fputws(L"[Привет Василий]\n", stdout); > fputwc(L"[Привет Василий]\n"[3], stdout); > return 0; > } > > I wonder what glibc's behavior is that it allows this; and how > emscripten folks can work around the musl behavior as well. > > Which environment variables could I set to control this, or is that not > possible? There are no environment variables that control the initial state of the program before setlocale() is called. The environment variables only affect the behavior of setlocale when it requests the system's/user's default locale (""). If you don't want the behavior to be dependent on locale, don't use the wide functions. fputs("[Привет Василий]\n", stdout) would work regardless of locale and would simply output the byte sequence. Of course to be meaningful this depends on both the translation charset and runtime charset being the same; they should of course both be UTF-8 anytime in this millennium. Rich