bug#66363: gdb-control-commands-regexp issues

[Eli Zaretskii]

> From: Mattias Engdegård <mattias.engdegard@gmail.com>
> 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?