Re: [PATCH] Fix ptype problem printing typedefs defined differently in different compilation units

[Fred Fish <fnf@specifix.com>]

On Saturday 11 February 2006 13:35, Daniel Jacobowitz wrote:
> Don't you get a warning compiling this?

No, I was building without -O, for better debugging of gdb, and that produces
the warning:

  cc1: warning: -Wuninitialized is not supported without -O

for every file, which I ignore.  Building with -O does indeed produce a
warning about val being uninitialized.

> It looks to me like, with objectprint set, ptype and whatis will now
> blow up; they call value_rtti_target_type without initializing val.

Yup.  The fix would be to remove the test of type==NULL and always
initialize val, whether or not ptype_eval finds a type to print.

Apparently we don't have any test in the gdb testsuite that checks
using objectprint, as there we no regressions when I ran it after the
change.

> Also ptype will now do the RTTI lookup; I'm not sure whether it
> should or not.

Not sure either, now that you point it out.

> The documentation for whatis and ptype leaves me way unenlightened
> about what the difference between them is supposed to be; perhaps we
> should eliminate the difference.

Mainly it appears that ptype is expected to print the entire type,
while whatis simply prints the basic info.  I.E.

    (gdb) ptype afoo
    type = struct foo {
        int x;
        int y;
    }

    (gdb) whatis afoo
    type = struct foo
    (gdb)

If we want to keep ptype from doing the RTTI lookup when objectprint is
set, it's easy enough to revert the part of the patch that simplifies
ptype_command into a simple call to whatis_exp.  The meat of the change
that makes "ptype 'foo.c'::afoo" work is the change to ptype_eval to
add the test for an OP_VAR_VALUE expression.  We should probably still
keep the patch to whatis_exp, with the fix to avoid a NULL val of course,
so that both ptype and whatis can use the 'file'::typename syntax.

-Fred