gdb/18: gdb can't parse "info func operator*" or "info func operator\*".

[chastain at redhat dot com]

>Number:         18
>Category:       gdb
>Synopsis:       gdb can't parse "info func operator*" or "info func operator\*".
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Feb 03 22:08:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Michael Chastain
>Release:        cvs 2001-02-02
>Organization:
>Environment:
Red Hat Linux 7
not dependent on environment
>Description:
"info func" is unable to access operator* and operator*= functions.
Neither "info func operator*" nor "info func operator\*" work.

"info func operator*" gets processed as a regex, which is a bit suprising but consistent with the matching available in "info func".
"info func operator\*" gets bonked in operator_chars() because it doesn't accept the '\' character.

"info func operator*=" and "info func operator\*=" have the same problems.
>How-To-Repeat:
Grab the executable for gdb.base/cplusfuncs and do "info func operator*" and "info func operator\*".
>Fix:
The problem is that operator_chars thinks it is parsing an operator name,
but search_symbols calls it with a string that holds a regexp that matches operator names.

One solution is for search_symbols to recognize when it has an operator name (it already has code for this).
When *opname is true, then search_symbols would insert '\\' characters in front of any metacharacters in the operator name.
This would make "info func operator*" work as I would naively expect.

Another solution is to change the interface to operator_chars so that it accepts strings that are regexps rather than strings thar are literals.
Specifically, operator_chars would accept constructions "operator\*".
I don't like this because (1) it is a quiet change to a public interface and (2) operator_chars may be used in other places besides here.

Whichever way you fix it, gdb.c++/cplusfuncs.exp already has tests for this.
>Release-Note:
>Audit-Trail:
>Unformatted: