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 BDF0B3842586 for ; Thu, 21 Apr 2022 15:47:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BDF0B3842586 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35174) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhZ21-0002qI-A9; Thu, 21 Apr 2022 11:47:45 -0400 Received: from [87.69.77.57] (port=2602 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 1nhZ20-0004as-Q0; Thu, 21 Apr 2022 11:47:45 -0400 Date: Thu, 21 Apr 2022 18:47:41 +0300 Message-Id: <83r15qqvz6.fsf@gnu.org> From: Eli Zaretskii To: Tom Tromey Cc: gdb-patches@sourceware.org In-Reply-To: <20220421143926.2550856-1-tromey@adacore.com> (message from Tom Tromey via Gdb-patches on Thu, 21 Apr 2022 08:39:26 -0600) Subject: Re: [PATCH] Handle encoding failures in Windows thread names References: <20220421143926.2550856-1-tromey@adacore.com> X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 21 Apr 2022 15:47:46 -0000 > Date: Thu, 21 Apr 2022 08:39:26 -0600 > From: Tom Tromey via Gdb-patches > Cc: Tom Tromey > > 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. I suggest to explain in a comment how this code detects encoding failures. The documentation of WideCharToMultiByte is not simple to understand in this regard, and "used_default" is not expressive enough to explain its role here, so I suggest not to rely on the reader to know those subtleties. Thanks.