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

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

5 okt. 2023 kl. 19.43 skrev Eli Zaretskii <eliz@gnu.org>:

> So the problem is only that 3 should be changed to the correct group
> number?

That would perhaps work, but it wouldn't be a very robust solution. There are many groups preceding that we don't care about, and the bug arose precisely because they were added without considering that a group was being used.

Better then to get rid of all groups save the one in use. (The proposed patch does that.)
That would make it much more difficult for the same bug to arise again.

> Here you are talking about some optimization of the regexp, or is it
> another bug?  If the latter, what is the bug here?

It's related. When the reference to subgroup 3 was added (30c0f81f9f), the tail looked like this:

  "\\([[:blank:]]+\\([^[:blank:]]*\\)\\)?$"
                  ^^^^^^^^^^^^^^^^^^^
and subgroup 3 was the second group in this substring (underlined above). Later (f71afd600a) the last `?` was changed into a `*`, but that made the contents of that group somewhat hazy because of the repetition:

  "\\([[:blank:]]+\\([^[:blank:]]*\\)\\)*$"
                                        ^
which doesn't leave us with a useful group for the purpose of detecting command arguments at all.
So the tail of the regexp has to be rewritten anyway, and we might as well do it in a more straightforward way. (The proposed patch does that as well.)

The reason I found this is that it contains a sub-pattern on the form (A+B*)* which is super-linear in general but usually easy to fix so that the result is actually more readable, yet faster.