From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2476 invoked by alias); 12 Jul 2011 20:09:03 -0000 Received: (qmail 2468 invoked by uid 22791); 12 Jul 2011 20:09:02 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_WEB,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Jul 2011 20:08:46 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LO800G00L5SLA00@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Tue, 12 Jul 2011 23:08:36 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.229.156.102]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LO800GE6LA9CKA0@a-mtaout23.012.net.il>; Tue, 12 Jul 2011 23:08:35 +0300 (IDT) Date: Tue, 12 Jul 2011 20:28:00 -0000 From: Eli Zaretskii Subject: Re: [doc patch] whatis vs. ptype - the difference In-reply-to: <20110712183130.GA15349@host1.jankratochvil.net> To: Jan Kratochvil Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <8339ibfef5.fsf@gnu.org> References: <20110712183130.GA15349@host1.jankratochvil.net> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-07/txt/msg00318.txt.bz2 > Date: Tue, 12 Jul 2011 20:31:30 +0200 > From: Jan Kratochvil > > The patch just describes the current behavior. With my English waiting for > a doc review. Thanks. I must confess that the new description is not much clearer than the old one. After reading it (more than once), I still have no clear idea of the differences between these two commands. It's obvious that ptype does a more thorough job that whatis, but what exactly each one does and does not do is still in the fog for me. Below I try to ask specific questions in the hope that they will allow to make this issue more clear. > +If @var{arg} is an expression (@pxref{Expressions, ,Expressions}), it is not > +actually evaluated, and any side-effecting operations (such as assignments or > +function calls) inside it do not take place. Why is this important? It doesn't belong to the differences between the two commands, AFAIK, does it? > @code{whatis} prints the type of > +@var{arg} as used in the source code The "as used in the source code" part is confusing. What exactly does it mean, and how, if at all, is that different from ptype? > possibly including any typedefs. "Possibly"? You mean it sometimes does and sometimes does not? If so, when does it? > +@code{whatis} never prints fields of compound types like @samp{struct}s. This part is clear. > +@code{whatis} unrolls in such case only one layer of outer typedef at a time. This sounds incorrect, because your example says: > +complex_t v; > [...] > (@value{GDBP}) whatis v > +type = complex_t That is, there's no "unrolling" here, not even of a single layer. Unless I misunderstood what you mean by "unrolling", that is. > +Any inner typedefs --- such as fields of @samp{struct} or typedefs at the > +pointer target --- are always preserved by both @code{whatis} and @code{ptype}. Not clear what that means. whatis doesn't show struct members at all, does it? If so, how can it "preserve" those fields? Btw, a stylistic point: don't leave whitespace around "---", it looks ugly in print. > +@code{ptype} always unrolls all outer typedefs contrary to @code{whatis}. Instead of talking about "unrolling", wouldn't it be better to say that ptype recursively looks up the definition of each type until it arrives at primitive data types, and prints the result only then? > +@code{ptype} of an expression (variable) will not print its real type including > +possible typedefs as present in the source code Not clear. The "real" part is getting in the way. Don't you mean "literal", not "real"? > -- use @code{whatis} for that ^^ Please use 3 dashes in a row, not 2. > +Any inner typedefs --- such as fields of @samp{struct} or typedefs at > +the pointer target --- are always preserved by both @code{whatis} and > +@code{ptype}. Not clear: what are "inner typedefs"? If a struct has a member that is itself a struct, what will ptype show about this member? Also, since whatis does not show struct members at all (AFAIU), saying "both" here is confusing and misleading, no? I hope answering these questions will allow to rephrase the text so it is both accurate and clear. Thanks again for working on this.