This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>, Chris Moller <cmoller at redhat dot com>, Keith Seitz <keiths at redhat dot com>
- Date: Thu, 03 Sep 2009 13:18:59 -0600
- Subject: Re: [Keith Seitz] Re: [tools-team] Status 2008-09-01
- References: <m31vmpku7t.fsf@fleche.redhat.com><20090902214348.GA32564@host0.dyn.jankratochvil.net>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> Just this is due the wrong printing defaults:
Jan> (gdb) p obj->num_
Jan> There is no member or method named num_.
Jan> (gdb) set print object on
Jan> (gdb) p obj->num_
Jan> $1 = 2
I'm really surprised that "set print object" affects this.
It seems to me that this should always follow the language rules, and
that "obj->num_" should therefore be an error. (I used to hold the
opposite position for Java, funnily enough, but I have come around.)
Instead I would expect this to work:
(gdb) set print object on
(gdb) print *obj
$1 = ... # something of type special_int_math
(gdb) print $.num_
$2 = whatever
That is, I think "set print object on" ought to affect the type of the
resulting history variable -- but not the type of any intermediate
values in an expression.
Jan> One should change this (+some other related options in
Jan> `user_print_options') and in some way fix the testsuite regressions
Jan> afterwards by one of:
I agree, we should change this default.
Tom