[Bug c++/17004] New: print base::operator char * passes in cpexprs.exp, but only accidentally

["dje at google dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17004

            Bug ID: 17004
           Summary: print base::operator char * passes in cpexprs.exp, but
                    only accidentally
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: c++
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com

I happened to create a gdb that failed this testcase in cpexprs.exp.

print base::operator char*

Looking at a pristine copy of HEAD to see what's going on I found that this
test passes, but only accidentally.

Parsing of the expression creates "operatorchar *" as the member fn to look up
in "base".  Note no space after operator, which is fine for operator+, etc.
It's a little confusing for "operator char *", though not a bug per se.

c-exp.y:

        |       OPERATOR conversion_type_id
                        { char *name;
                          long length;
                          struct ui_file *buf = mem_fileopen ();

                          c_print_type ($2, NULL, buf, -1, 0,
                                        &type_print_raw_options);
                          name = ui_file_xstrdup (buf, &length);
                          ui_file_delete (buf);
                          $$ = operator_stoken (name);
                          free (name);
                        }

strcmp is used to do member fn comparisons here in
valops.c:value_struct_elt_for_reference:

    for (i = TYPE_NFN_FIELDS (t) - 1; i >= 0; --i)
      {
        const char *t_field_name = TYPE_FN_FIELDLIST_NAME (t, i);
        char dem_opname[64];

        if (strncmp (t_field_name, "__", 2) == 0
            || strncmp (t_field_name, "op", 2) == 0
            || strncmp (t_field_name, "type", 4) == 0)
          {
            if (cplus_demangle_opname (t_field_name,
                                       dem_opname, DMGL_ANSI))
              t_field_name = dem_opname;
            else if (cplus_demangle_opname (t_field_name,
                                            dem_opname, 0))
              t_field_name = dem_opname;
          }
        if (t_field_name && strcmp (t_field_name, name) == 0)

That fails, t_field_name is "operator char *".
Later as a last resort we try this:

    /* As a last chance, pretend that CURTYPE is a namespace, and look          
       it up that way; this (frequently) works for types nested inside          
       classes.  */

    return value_maybe_namespace_elt (curtype, name,
                                      want_address, noside);

And that works (for reasons I didn't look into).

One could argue the bug is t_field_name should be "operatorchar *".
Maybe cplus_demangle_opname is responsible for doing that.
I'm not sure.
Still, IWBN if it were spelled "operator char *".

Or maybe we should be using strcmp_iw here instead of strcmp.
[Not my preferred solution - I'd rather be strict, requiring strcmp, but my
opinion may change as I dig deeper - though this bug has a low priority for me
right now.]

-- 
You are receiving this mail because:
You are on the CC list for the bug.