From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Hi9oGobQ82ha8z0AWB0awg (envelope-from ) for ; Sat, 18 Oct 2025 13:38:14 -0400 Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (768-bit key; unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=R+f1X4Et; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 5348F1E0BC; Sat, 18 Oct 2025 13:38:14 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2DE951E047 for ; Sat, 18 Oct 2025 13:38:13 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 482BE3858C25 for ; Sat, 18 Oct 2025 17:38:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 482BE3858C25 Authentication-Results: sourceware.org; dkim=fail reason="signature verification failed" (768-bit key, unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=R+f1X4Et Received: from omta40.uswest2.a.cloudfilter.net (omta40.uswest2.a.cloudfilter.net [35.89.44.39]) by sourceware.org (Postfix) with ESMTPS id CDFEE3857BB9 for ; Sat, 18 Oct 2025 17:19:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CDFEE3857BB9 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CDFEE3857BB9 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=35.89.44.39 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760807951; cv=none; b=gYtCV2ux3GPeSYr22g0U/SB3o94Wfy8Ge2u21xCWchrFb6HrO8irmvhrK0hYgIHNw1Kc2m5ptrqAnViXipSmOCIduCERUuXtAcJiyVoDI7DQrwS9DUs8xZhUy/c0ipGIHsgsP2i/LqxSaCJqv7hRUVADfCdFrbOm8XAvIZNdmm4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1760807951; c=relaxed/simple; bh=jZHSstBIbacmDAQZxo1/e5lSNSzS7sy4qxk80WTkcD4=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=rKjXrRQCwNQ6hw/oGlerGYR7GDWwb77i0s5leXUPZkaIi7bJMi1cRORlVOvgQRRawfk3I+oWY+HWW4c22a5AIacltnC73nvrmOYe6waj2dQ8mX/+5ZjweU68ulp/I+qy4zb92O+45JP36ICMVneDS/iERnzk1c34sYMY8juOC3s= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CDFEE3857BB9 Received: from eig-obgw-5007b.ext.cloudfilter.net ([10.0.29.167]) by cmsmtp with ESMTPS id A4fMvLNtGaPqLAAaDvYd78; Sat, 18 Oct 2025 17:19:09 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id AAaCvf9sgFT7uAAaDvjTIR; Sat, 18 Oct 2025 17:19:09 +0000 X-Authority-Analysis: v=2.4 cv=Du5W+H/+ c=1 sm=1 tr=0 ts=68f3cc0d a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=x6icFKpwvdMA:10 a=ItBw4LHWJt0A:10 a=nPTvAU1BTT4EzzkQcoMA:9 a=VS4QxaUSPT0UtbFnIvSC:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=xJ/G6dk91qXd5gjbJep36iAJRKk3ZEtWXfz+VTM2vqM=; b=R+f1X4EtzMhn/smkNP8yqRPpB4 XUURYDB36EbZXtNYDjfMM71WRI8PWAzI8xxBX11mIYYkLbt0PHDy1q+GDTm3hsaCMzMdotHlTGhUv hLilTeO6lPo387CdjgJifCfi+; Received: from 97-122-110-68.hlrn.qwest.net ([97.122.110.68]:42210 helo=prentzel) by box5379.bluehost.com with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vAAaC-00000003Hw8-2sP6; Sat, 18 Oct 2025 11:19:08 -0600 From: Tom Tromey To: Tom de Vries Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH] [gdb/testsuite] Fix gdb.tui/resize-3.exp on ppc64-linux In-Reply-To: (Tom de Vries's message of "Sat, 18 Oct 2025 10:21:58 +0200") References: <20251017133957.2464782-1-tdevries@suse.de> <87cy6lr4xw.fsf@tromey.com> X-Attribution: Tom Date: Sat, 18 Oct 2025 11:19:07 -0600 Message-ID: <87frbgb01g.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 97.122.110.68 X-Source-L: No X-Exim-ID: 1vAAaC-00000003Hw8-2sP6 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-110-68.hlrn.qwest.net (prentzel) [97.122.110.68]:42210 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfAkR9UOO1/xEN1fVwiSOcxoGdfhS+A0CO0aC/BBinf8/0sLqP86GEFWaJ2s+O1nd167iDqJfJ2W+ohOmiiauP0O8pEs4byZR6mQgLI3bnpAJV55yWAVD hZrLoogqNtbjE71rBnhr/yhQ4bmiq5csz7yIcruL8KJx7dkbqXQqz2Je6HDHzqM3JxmitvhOUiAbWikFC+xUkjbGPPxFOLY8D0Q= X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Tom> - "$hex\\s+ + [string cat $hex {\s+} "<" ([string_to_regexp .])? "foo"] >> Personally I find this a lot less readable than just writing out the >> regular expression. Tom> I find this style much less readable: Tom> ... Tom> set re "$hex\\s+<(\\.)?foo" Tom> ... Tom> That is, I don't understand why you would join logically separate Tom> parts of the regexp together and force readers of the regexp to go Tom> through the process of separating them out again. The specific reason I do find this more readable is that reading a regular expression is a skill I already have, whereas decoding: [string cat $hex {\s+} "<" ([string_to_regexp .])? "foo"] requires picking through each part and trying to understand what the point is. Tom> It's also error prone, especially where the dot is concerned: Tom> - if you forget the second backslash on the s, you get a mismatch and Tom> it's easily spotted. Tom> - if you forget the second backslash on the dot, you still get a match, Tom> but it'll match any character, say the a in "0x00c0ffee ". Tom> I've seen many examples of this mistake in the testsuite sources. This is not a mistake per se, I think. Like, it isn't an instance of someone being confused as to what to write and picking the wrong one. I think it is rather laziness about the quoting combined with the recognition that it is hardly likely to matter. Not that I'm supporting laziness in all cases, but a lot of times it really just isn't important. Like, in this case, if one wrote "<.?foo" would this really ever trigger erroneously? In your example above, where does "afoo" come from? It seems to me that a situation like that can be solved by picking more distinct symbol names, something we've already had to do plenty of times when it turns out that some C library happens to define the same symbol name as a test case. Another thought here is that regexps interact badly with Tcl double quotes. But they aren't as bad when using braces. So maybe that's another approach. Just to ground this discussion a bit, I don't really care about this particular test. You can land this patch if you want. I'm not likely to ever look at it again. However this is more about the future direction of the test suite in general. I would be against a more global replacement of relatively straightforward (to me) regular expressions with concatenations of function calls, not to mention requiring this very wordy approach in patches. Today I wrote a Tcl implementation of the "quotemeta" thing from the AdaCore internal test suite. We discussed it once before. I'll attach it to that bug. It does help quite a bit (IMO) but unfortunately not with the particular problem in this thread. Tom