From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19957 invoked by alias); 14 Dec 2007 21:27:03 -0000 Received: (qmail 19948 invoked by uid 22791); 14 Dec 2007 21:27:03 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Dec 2007 21:26:59 +0000 Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id lBELQsSc008241 for ; Fri, 14 Dec 2007 13:26:54 -0800 Received: from rv-out-0910.google.com (rvbk15.prod.google.com [10.140.87.15]) by zps36.corp.google.com with ESMTP id lBELQWmw029911 for ; Fri, 14 Dec 2007 13:26:54 -0800 Received: by rv-out-0910.google.com with SMTP id k15so1082252rvb.2 for ; Fri, 14 Dec 2007 13:26:53 -0800 (PST) Received: by 10.141.203.7 with SMTP id f7mr2212440rvq.185.1197667613885; Fri, 14 Dec 2007 13:26:53 -0800 (PST) Received: by 10.141.142.4 with HTTP; Fri, 14 Dec 2007 13:26:53 -0800 (PST) Message-ID: Date: Sat, 15 Dec 2007 13:15:00 -0000 From: "Doug Evans" To: gdb-patches@sourceware.org Subject: Re: [RFA] patch for 2384, dangling TYPE_VPTR_BASETYPE In-Reply-To: <20071214002920.GA1208@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071214002920.GA1208@caradoc.them.org> 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: 2007-12/txt/msg00201.txt.bz2 On Dec 13, 2007 4:29 PM, Daniel Jacobowitz wrote: > On Thu, Dec 13, 2007 at 04:10:55PM -0800, Doug Evans wrote: > > Ok to check in? Or any suggestions for what's needed instead? > > Your patch seems strange to me. Do we need the new fieldno / > basetype, or not? If we don't, we shouldn't be calculating it at all; > if we do, there should be something detectable which breaks when you > do this. It's not just a cache, since the interface doesn't offer any > other way to return the new fieldno / basetype besides in-place > modification. Hold the fort, I think I see what you're saying now. I'll send another patch for review.