From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#66363: gdb-control-commands-regexp issues Date: Thu, 05 Oct 2023 20:43:40 +0300 Message-ID: <83jzs12cdv.fsf@gnu.org> References: <83wmw12fu5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18958"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66363@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 05 19:44:18 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qoSOX-0004hX-4N for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Oct 2023 19:44:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qoSO1-0004f6-Dd; Thu, 05 Oct 2023 13:43:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qoSO0-0004eY-4F for bug-gnu-emacs@gnu.org; Thu, 05 Oct 2023 13:43:44 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qoSNz-0004qQ-So for bug-gnu-emacs@gnu.org; Thu, 05 Oct 2023 13:43:43 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qoSOH-0007MT-Rc for bug-gnu-emacs@gnu.org; Thu, 05 Oct 2023 13:44:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Oct 2023 17:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66363 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 66363-submit@debbugs.gnu.org id=B66363.169652783928281 (code B ref 66363); Thu, 05 Oct 2023 17:44:01 +0000 Original-Received: (at 66363) by debbugs.gnu.org; 5 Oct 2023 17:43:59 +0000 Original-Received: from localhost ([127.0.0.1]:48463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qoSOE-0007M5-Ps for submit@debbugs.gnu.org; Thu, 05 Oct 2023 13:43:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qoSOB-0007Lp-Rs for 66363@debbugs.gnu.org; Thu, 05 Oct 2023 13:43:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qoSNo-0004kU-5n; Thu, 05 Oct 2023 13:43:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=s52rkA5r1LD3RNCKB6fu8EDFsSmP6sMsEMHKBzue6HI=; b=R2MiY7vl8DcHwTHrGcdB UqcbLNRlFLp+hSb91xnhCwkhT+IL6estGxG1RMhZfL8OOlhekhQUbfXnbCRpK4YDwErCSe4cLSZrp 2TziXvpwS34mqyb4BNkyxQ17C1aFjkNpfIE13Yh2kXtyBX6rvj0+IkZ7kaG7ruCAdzrwuuE/wzYN1 DtcyiRRvW54pqrJ/2S6lO/ard1maPIIM3yzwsDvclykrm2jbjYZa65V7+7vXyUa9GWH2xEmc22btl 4bHmYsn33/VI35DE/WFhKBfNfmdgJyjzgg7IyLTNqqv5zrcHek1hOVy9HoU5uHSmmIpNooUoMQLL1 XCAktFxbNenpew==; In-Reply-To: (message from Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= on Thu, 5 Oct 2023 19:16:32 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:271906 Archived-At: > From: Mattias Engdegård > Date: Thu, 5 Oct 2023 19:16:32 +0200 > Cc: 66363@debbugs.gnu.org > > > I'd appreciate a few examples of using this that don't work correctly > > (or not at all), as it is otherwise not easy to understand the > > problem, and much less the proposed solution and how to test it. > > I don't have any examples but the problems are clear from reading the code. > The regexp is defined by: > > > (defvar gdb-python-guile-commands-regexp > > "python\\|python-interactive\\|pi\\|guile\\|guile-repl\\|gr" > > "Regexp that matches Python and Guile commands supported by GDB.") > > > > (defvar gdb-control-commands-regexp > > (concat > > "^\\(" > > "comm\\(a\\(n\\(ds?\\)?\\)?\\)?\\|if\\|while" > > "\\|def\\(i\\(ne?\\)?\\)?\\|doc\\(u\\(m\\(e\\(nt?\\)?\\)?\\)?\\)?\\|" > > gdb-python-guile-commands-regexp > > "\\|while-stepping\\|stepp\\(i\\(ng?\\)?\\)?\\|ws\\|actions" > > "\\|expl\\(o\\(re?\\)?\\)?" > > "\\)\\([[:blank:]]+\\([^[:blank:]]*\\)\\)*$") > > "Regexp matching GDB commands that enter a recursive reading loop. > > As long as GDB is in the recursive reading loop, it does not expect > > commands to be prefixed by \"-interpreter-exec console\".") > > which results in the string regexp > > > "^\\(comm\\(a\\(n\\(ds?\\)?\\)?\\)?\\|if\\|while\\|def\\(i\\(ne?\\)?\\)?\\|doc\\(u\\(m\\(e\\(nt?\\)?\\)?\\)?\\)?\\|python\\|python-interactive\\|pi\\|guile\\|guile-repl\\|gr\\|while-stepping\\|stepp\\(i\\(ng?\\)?\\)?\\|ws\\|actions\\|expl\\(o\\(re?\\)?\\)?\\)\\([[:blank:]]+\\([^[:blank:]]*\\)\\)*$" > > It is used in one place only: > > > (let* ((control-command-p (string-match gdb-control-commands-regexp string)) > > (command-arg (and control-command-p (match-string 3 string))) > > As you can see it refers to group 3, which is matched by "\\(n\\(ds?\\)?\\)" -- clearly not what anybody intended. So the problem is only that 3 should be changed to the correct group number? > As for the tail, even if the match group is corrected it's a rather roundabout way of checking whether there is a non-blank character after the command (and is written using nested repetitions which is how this came to my attention). Here you are talking about some optimization of the regexp, or is it another bug? If the latter, what is the bug here?