Handling of structure dereferencing

Handling of structure dereferencing

[Daniel Jacobowitz]

Right now, and historically, gdb has accepted things like:
  struct foo {char a} *b, **c, ***d;

(gdb) print b.a
(gdb) print d->a

This is tied to a collection of very messy values handling, where we will
dereference pointers "as far as possible" in a lot of cases (like when
looking for members).  It makes printing structs somewhat "easier", but in
my opinion, also rather more confusing.

So, straw poll: how would people feel about:
 - not letting this happen; only explicit dereferencing

[random thought]
 - and maybe, a print flag or something to allow us to print both the
  value of a pointer and the dereferenced type by default.  I spend a lot
  of time doing "print longthing" up arrow "print longthing[0]" up arrow
  "print longthing[0].otherfield" to walk down things like "struct type";
  it would be nice if there were a way to do the first two steps at the same
  time, since they are so very often associated.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Handling of structure dereferencing

[Eli Zaretskii]

> Date: Thu, 6 Dec 2001 12:07:39 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> Right now, and historically, gdb has accepted things like:
>   struct foo {char a} *b, **c, ***d;
> 
> (gdb) print b.a
> (gdb) print d->a

You mean, instead of b->a and (**d)->a, yes?

> So, straw poll: how would people feel about:
>  - not letting this happen; only explicit dereferencing

I don't mind in this specific case, but I wonder whether there isn't
some iceberg of which this is only a tip.  We do want GDB to continue
to print a string when you say "p str", and str is a pointer to a
string, right?  It's quite possible that the same machinery which
supports printing arrays also causes the above.

Re: Handling of structure dereferencing

[Daniel Jacobowitz]

On Thu, Dec 06, 2001 at 09:47:50PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 6 Dec 2001 12:07:39 -0500
> > From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > Right now, and historically, gdb has accepted things like:
> >   struct foo {char a} *b, **c, ***d;
> > 
> > (gdb) print b.a
> > (gdb) print d->a
> 
> You mean, instead of b->a and (**d)->a, yes?

Yes, exactly.

> > So, straw poll: how would people feel about:
> >  - not letting this happen; only explicit dereferencing
> 
> I don't mind in this specific case, but I wonder whether there isn't
> some iceberg of which this is only a tip.  We do want GDB to continue
> to print a string when you say "p str", and str is a pointer to a
> string, right?  It's quite possible that the same machinery which
> supports printing arrays also causes the above.

I don't think that's the case; printing a char* does not involve
implicit dereferencing (if it did, you'd only get the first character).

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Handling of structure dereferencing

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

Daniel> Right now, and historically, gdb has accepted things like:
Daniel>   struct foo {char a} *b, **c, ***d;

Daniel> (gdb) print b.a

Daniel> So, straw poll: how would people feel about:
Daniel>  - not letting this happen; only explicit dereferencing


I use `p PTR.field' instead of `p PTR->field' all the time in gdb.
I'd prefer to keep it if possible.
However, I do notice that I only use this in the `b' case.
I don't recall ever using it when there is more than one level of
indirection involved.

Tom

Re: Handling of structure dereferencing

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Date: 06 Dec 2001 16:45:56 -0700
> 
> However, I do notice that I only use this in the `b' case.
> I don't recall ever using it when there is more than one level of
> indirection involved.

Yeah, that wiould be quite unnatiral, don't you think?  I wonder how
many users even know about this feature.  I didn't.

Re: Handling of structure dereferencing

[Andrew Cagney]

> On Thu, Dec 06, 2001 at 09:47:50PM +0200, Eli Zaretskii wrote:
> 
>> > Date: Thu, 6 Dec 2001 12:07:39 -0500
>> > From: Daniel Jacobowitz <drow@mvista.com>
>> > 
>> > Right now, and historically, gdb has accepted things like:
>> > struct foo {char a} *b, **c, ***d;
>> > 
>> > (gdb) print b.a
>> > (gdb) print d->a


b->a and b.a are probably commonly used - don't some languages even 
accept both forms?  As for ``d.a'', I don't have an opinion - hmm, now 
that I know about it I might just start using it :-(

Do you know which code was involved?  I can dig up a little bit more of 
the history.


> Yes, exactly.
> 
> 
>> > So, straw poll: how would people feel about:
>> > - not letting this happen; only explicit dereferencing
> 
>> 
>> I don't mind in this specific case, but I wonder whether there isn't
>> some iceberg of which this is only a tip.  We do want GDB to continue
>> to print a string when you say "p str", and str is a pointer to a
>> string, right?  It's quite possible that the same machinery which
>> supports printing arrays also causes the above.
> 
> 
> I don't think that's the case; printing a char* does not involve
> implicit dereferencing (if it did, you'd only get the first character).


GDB certainly does pull some magic though - ``(gdb) print (char*)foo'' 
prints a string up to NUL.  I know this cos I've a fuzzy memory of one 
version of GDB breaking this behavour and the bug report triggering a 
long argument over the advantages/disadvantages of such features.

Andrew

Re: Handling of structure dereferencing

[Daniel Berlin]

On Thu, 3 Jan 2002, Andrew Cagney wrote:

> > On Thu, Dec 06, 2001 at 09:47:50PM +0200, Eli Zaretskii wrote:
> > 
> >> > Date: Thu, 6 Dec 2001 12:07:39 -0500
> >> > From: Daniel Jacobowitz <drow@mvista.com>
> >> > 
> >> > Right now, and historically, gdb has accepted things like:
> >> > struct foo {char a} *b, **c, ***d;
> >> > 
> >> > (gdb) print b.a
> >> > (gdb) print d->a
> 
> 
> b->a and b.a are probably commonly used - don't some languages even 
> accept both forms?  As for ``d.a'', I don't have an opinion - hmm, now 
> that I know about it I might just start using it :-(
> 
I switch them all the time.
For pointers, i usually start by printing [0] of it, then [0].some 
member[0], etc.
I almost never use ->.
Why should I have to care whether the object is really a pointer or not to 
be able to print a member?
I only care about printing the member, or else i wouldn't have asked for 
it.

Is there some good reason to not allow either to work?
IE is allowing it breaking something else, or preventing something else 
from being implemented?
If not, why make it *harder* for users to do what they want?

I don't want to have to remember whether in the expression "a.x.d.b.c", 
whether b is a poiner or not. I only care about seeing c.

If this is changed, it would, at least for me (and i imagine a large 
number 
of others) make gdb a lot harder to use.


--Dan

Re: Handling of structure dereferencing

[Daniel Jacobowitz]

On Tue, Feb 05, 2002 at 12:30:41PM -0500, Daniel Berlin wrote:
> On Thu, 3 Jan 2002, Andrew Cagney wrote:
> 
> > > On Thu, Dec 06, 2001 at 09:47:50PM +0200, Eli Zaretskii wrote:
> > > 
> > >> > Date: Thu, 6 Dec 2001 12:07:39 -0500
> > >> > From: Daniel Jacobowitz <drow@mvista.com>
> > >> > 
> > >> > Right now, and historically, gdb has accepted things like:
> > >> > struct foo {char a} *b, **c, ***d;
> > >> > 
> > >> > (gdb) print b.a
> > >> > (gdb) print d->a
> > 
> > 
> > b->a and b.a are probably commonly used - don't some languages even 
> > accept both forms?  As for ``d.a'', I don't have an opinion - hmm, now 
> > that I know about it I might just start using it :-(
> > 
> I switch them all the time.
> For pointers, i usually start by printing [0] of it, then [0].some 
> member[0], etc.
> I almost never use ->.
> Why should I have to care whether the object is really a pointer or not to 
> be able to print a member?
> I only care about printing the member, or else i wouldn't have asked for 
> it.
> 
> Is there some good reason to not allow either to work?
> IE is allowing it breaking something else, or preventing something else 
> from being implemented?
> If not, why make it *harder* for users to do what they want?
> 
> I don't want to have to remember whether in the expression "a.x.d.b.c", 
> whether b is a poiner or not. I only care about seeing c.
> 
> If this is changed, it would, at least for me (and i imagine a large 
> number 
> of others) make gdb a lot harder to use.

OK, this issue is closed then.  People seem to use it as a feature.  I
may look in to allowing it -only- from the prompt though.

It's just a messiness issue; in functions that deal with values
internally, it is unclear what they should do if they get a pointer,
and when they can expect a pointer, etc.

Some day I'll have the free time to bash on value handling and I'll
look on moving the behavior up to the frontend.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Handling of structure dereferencing

[Michael Elizabeth Chastain]

> So, straw poll: how would people feel about:
>  - not letting this happen; only explicit dereferencing

As a user, this would be fine with me, although I can see how it would
bother other users.

It's 10x more important to me that "print foo.a" and "print foo.b()"
never return incorrect data.  I can live with virtual baseclass botch,
but when the debugger prints an incorrect value, that destroys my
faith in all the other values it prints.  If getting rid of the
implicit dereference helps, I'm all for it.

Michael C