From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51770 invoked by alias); 4 Aug 2015 10:48:33 -0000 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 Received: (qmail 51740 invoked by uid 89); 4 Aug 2015 10:48:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f174.google.com Received: from mail-wi0-f174.google.com (HELO mail-wi0-f174.google.com) (209.85.212.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 04 Aug 2015 10:48:26 +0000 Received: by wicgj17 with SMTP id gj17so144344295wic.1 for ; Tue, 04 Aug 2015 03:48:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.81.137 with SMTP id a9mr7048711wjy.155.1438685302932; Tue, 04 Aug 2015 03:48:22 -0700 (PDT) Received: by 10.27.11.33 with HTTP; Tue, 4 Aug 2015 03:48:22 -0700 (PDT) In-Reply-To: <55C07787.9090605@adacore.com> References: <55C07787.9090605@adacore.com> Date: Tue, 04 Aug 2015 10:48:00 -0000 Message-ID: Subject: Re: [PATCH v3 1/2] D: Support looking up symbols in the current and imported modules From: Iain Buclaw To: Pierre-Marie de Rodat Cc: GDB Patches , Doug Evans Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00068.txt.bz2 On 4 August 2015 at 10:27, Pierre-Marie de Rodat wrote: > Hello, > > On 08/03/2015 08:00 PM, Iain Buclaw wrote: >> >> Rebased this against master, in particular to make it compatible with >> the recent block_symbol additions. I don't have a GCC-4.1 compiler at >> hand, but I don't think I'm doing anything that may trigger build >> warnings. Pierre, maybe you want to confirm? > > > Well, I don't have easy access to one neither. ;-) I had a very quick look > at your patch and it seems that all usage of block_symbol variables are > dominated by at least one affectation (sym = lookup...), so I guess the > problem Ulrich and Steve noticed should not arise here. > > ... except maybe in one place: in find_symbol_in_baseclass, the returned > value is uninitialized if we don't enter the FOR loop (is that only possible > in practice?). So what about providing {NULL, NULL} as an ininialization > value to "sym", there? > > -- > Pierre-Marie de Rodat Nice catch! Yes, that seems reasonable. I think in the original it was initialized to NULL... Regards Iain.