From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 87DF33857B84 for ; Thu, 2 Jun 2022 16:07:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 87DF33857B84 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34016) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nwnLt-0001OR-JF; Thu, 02 Jun 2022 12:07:13 -0400 Received: from [87.69.77.57] (port=3014 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nwnLj-0008Tu-Rq; Thu, 02 Jun 2022 12:07:09 -0400 Date: Thu, 02 Jun 2022 19:07:14 +0300 Message-Id: <83tu93dp71.fsf@gnu.org> From: Eli Zaretskii To: Jon Turney Cc: tromey@adacore.com, gdb-patches@sourceware.org In-Reply-To: <6f7e3db5-76f4-e21d-edbd-2cd1993a7bdd@dronecode.org.uk> (message from Jon Turney on Thu, 2 Jun 2022 15:19:21 +0100) Subject: Re: [PATCH] Handle encoding failures in Windows thread names References: <20220421143926.2550856-1-tromey@adacore.com> <6f7e3db5-76f4-e21d-edbd-2cd1993a7bdd@dronecode.org.uk> X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2022 16:07:15 -0000 > Date: Thu, 2 Jun 2022 15:19:21 +0100 > From: Jon Turney > > > diff --git a/gdb/nat/windows-nat.c b/gdb/nat/windows-nat.c > > index bd1b9459145..7a4e804f891 100644 > > --- a/gdb/nat/windows-nat.c > > +++ b/gdb/nat/windows-nat.c > > @@ -119,12 +119,19 @@ windows_thread_info::thread_name () > > HRESULT result = GetThreadDescription (h, &value); > > if (SUCCEEDED (result)) > > { > > - size_t needed = wcstombs (nullptr, value, 0); > > - if (needed != (size_t) -1) > > + int needed = WideCharToMultiByte (CP_ACP, 0, value, -1, nullptr, 0, > > + nullptr, nullptr); > > + if (needed != 0) > > { > > - name.reset ((char *) xmalloc (needed)); > > - if (wcstombs (name.get (), value, needed) == (size_t) -1) > > - name.reset (); > > + BOOL used_default = FALSE; > > + gdb::unique_xmalloc_ptr new_name > > + ((char *) xmalloc (needed)); > > + if (WideCharToMultiByte (CP_ACP, 0, value, -1, > > + new_name.get (), needed, > > + nullptr, &used_default) == needed > > + && !used_default > > + && strlen (new_name.get ()) > 0) > > + name = std::move (new_name); > > } > > LocalFree (value); > > } > > This is probably wrong on Cygwin (as the target encoding should be > Cygwin's conception of the locale, not the Windows codepage). What does CP_ACP does on Cygwin? is it different from what that does in native Windows programs? Anyway, for Cygwin I think we should replace CP_ACP with CP_UTF8, don't you think?