From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-042.btinternet.com (mailomta4-sa.btinternet.com [213.120.69.10]) by sourceware.org (Postfix) with ESMTPS id EEB90396E029 for ; Thu, 2 Jun 2022 14:19:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EEB90396E029 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from sa-prd-rgout-005.btmx-prd.synchronoss.net ([10.2.38.8]) by sa-prd-fep-042.btinternet.com with ESMTP id <20220602141922.BLOZ3231.sa-prd-fep-042.btinternet.com@sa-prd-rgout-005.btmx-prd.synchronoss.net>; Thu, 2 Jun 2022 15:19:22 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 6139452E27496D05 X-Originating-IP: [86.139.167.41] X-OWM-Source-IP: 86.139.167.41 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvfedrledvgdejvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepffekiefgudejheetudeigfejledtleegleetkeduteeftdfffefhueefgfeutedtnecukfhppeekiedrudefledrudeijedrgedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurddutdehngdpihhnvghtpeekiedrudefledrudeijedrgedupdhmrghilhhfrhhomhepjhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhdpnhgspghrtghpthhtohepvddprhgtphhtthhopehguggsqdhprghttghhvghssehsohhurhgtvgifrghrvgdrohhrghdprhgtphhtthhopehtrhhomhgvhiesrggurggtohhrvgdrtghomh X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.105] (86.139.167.41) by sa-prd-rgout-005.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 6139452E27496D05; Thu, 2 Jun 2022 15:19:22 +0100 Message-ID: <6f7e3db5-76f4-e21d-edbd-2cd1993a7bdd@dronecode.org.uk> Date: Thu, 2 Jun 2022 15:19:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH] Handle encoding failures in Windows thread names Content-Language: en-GB To: Tom Tromey , gdb-patches@sourceware.org References: <20220421143926.2550856-1-tromey@adacore.com> From: Jon Turney In-Reply-To: <20220421143926.2550856-1-tromey@adacore.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1200.0 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_NONE, 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 14:19:25 -0000 On 21/04/2022 15:39, Tom Tromey via Gdb-patches wrote: > Internally at AdaCore, we noticed that the new Windows thread name > code could fail. First, it might return a zero-length string, but in > gdb conventions it should return nullptr instead. Second, an encoding > failure could wind up showing replacement characters to the user; this > is confusing and not useful; it's better to recognize such errors and > simply discard the name. This patch makes both of these changes. > --- > gdb/nat/windows-nat.c | 17 ++++++++++++----- > 1 file changed, 12 insertions(+), 5 deletions(-) > > 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).