From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27104 invoked by alias); 14 Jan 2005 23:29:58 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27063 invoked from network); 14 Jan 2005 23:29:49 -0000 Received: from unknown (HELO sccrmhc12.comcast.net) (204.127.202.56) by sourceware.org with SMTP; 14 Jan 2005 23:29:49 -0000 Received: from [10.0.1.2] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (sccrmhc12) with SMTP id <20050114232948012002hbtfe>; Fri, 14 Jan 2005 23:29:48 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 14 Jan 2005 23:29:00 -0000 Subject: Re: [RFA] initialize err variable in load_section_callback() From: Paul Schlie To: CC: "Theodore A. Roth" , Andrew Cagney Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-01/txt/msg00166.txt.bz2 If preferred, here's an alternate fix: In File target.c, int target_write_memory_partial (CORE_ADDR memaddr, char *buf, int len, int *err) { if (target_xfer_partial_p ()) + { + *err = 0; return target_xfer_partial (target_stack, TARGET_OBJECT_MEMORY, NULL, NULL, buf, memaddr, len); + } else return target_xfer_memory_partial (memaddr, buf, len, 1, err); } target_xfer_partial nor it's predecessor sets *err, therefore uninitialized. (bug introduced in version 1.83, by checkin on 9/30/04 by Andrew Cagney) > From: Paul Schlie > Date: Tue, 04 Jan 2005 02:31:39 -0500 > To: > Cc: "Theodore A. Roth" , Andrew Cagney > Subject: Re: [RFA] initialize err variable in load_section_callback() > > Might Ted please be given authorization to check his October patch into > both the 6.3 and head branches, as it fixes an uninitialized variable problem > which has already been subsequently independently found with identical fixes > proposed at least a few times since: > > http://sources.redhat.com/ml/gdb-patches/2004-10/msg00324.html > > (Although there appeared to be some discussion with Andrew on the subject, > this fix should be considered the least fragile way to guarantee that > the err variable declared within this function's scope is initialized, > as it's likely too fragile to assume that all functions which may signal > errors, explicitly also signal success [other than via the absents of an > error, which typically necessitates the utilized shared signaling variable > be initialized as being error-free]. Where then if there is a desire to > check/refined all error signaling functions within GDB such that they both > explicitly signal success and failure, and guarantee that at least one > such function is always called to initialize otherwise un-initialized error > variables prior to being tested, this may be done independently of this > proposed simple less fragile quick fix.) >