From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 348 invoked by alias); 22 Jul 2008 00:53:07 -0000 Received: (qmail 32704 invoked by uid 22791); 22 Jul 2008 00:53:06 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 Jul 2008 00:52:49 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6M0qiTT003355; Mon, 21 Jul 2008 20:52:44 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6M0qhcs032565; Mon, 21 Jul 2008 20:52:43 -0400 Received: from opsy.redhat.com (vpn-10-106.bos.redhat.com [10.16.10.106]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6M0qgn1031897; Mon, 21 Jul 2008 20:52:43 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 64D78378245; Mon, 21 Jul 2008 18:52:42 -0600 (MDT) To: ppluzhnikov@google.com (Paul Pluzhnikov) Cc: gdb-patches@sourceware.org Subject: Re: [RFC] [patch] 'p->x' vs. 'p.x' and 'print object on' References: <20080717214839.6AE253A67B6@localhost> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Tue, 22 Jul 2008 00:53:00 -0000 In-Reply-To: <20080717214839.6AE253A67B6@localhost> (Paul Pluzhnikov's message of "Thu\, 17 Jul 2008 14\:48\:39 -0700 \(PDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2008-07/txt/msg00399.txt.bz2 >>>>> "Paul" == Paul Pluzhnikov writes: Paul> Long time GDB users are somewhat used to 'p->x' and 'p.x' meaning Paul> the same thing. But, as test case below demonstrates, they don't Paul> mean the same thing when 'set print object on' is in effect. FWIW, I like this. I was always confused when I printed an object and saw a field, but was then unable to print the field directly. However, I recall bringing this up once, in the distant past. Someone pointed out a difficulty with this approach: there might be one field 'x' that would be used with the declared type, but another field, also named 'x', that would be used with the actual type. So, this could potentially be confusing (albeit in an already confusing situation). Maybe this can be documented or otherwise resolved. Also, IMO this patch could use an associated test case. Tom