From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27985 invoked by alias); 27 Jan 2005 19:38:06 -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 27752 invoked from network); 27 Jan 2005 19:37:57 -0000 Received: from unknown (HELO sccrmhc13.comcast.net) (204.127.202.64) by sourceware.org with SMTP; 27 Jan 2005 19:37:57 -0000 Received: from [10.0.1.2] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (sccrmhc13) with SMTP id <2005012719375601600igavre>; Thu, 27 Jan 2005 19:37:56 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 27 Jan 2005 19:38:00 -0000 Subject: PING: [RFA] initialize err variable in load_section_callback() From: Paul Schlie To: Andrew Cagney CC: , "Theodore A. Roth" 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/msg00259.txt.bz2 Andrew, As it's been 3 months since this patch was posed which correctly fixes a bug introduced a few weeks earlier by a check-in you made late September '04, might you please consider checking this fix in please? It would be very helpful if this can be done for both 6.3.x and HEAD in support of targets which rely on this code path remaining functional. [ For reference, although you had raised the question if this was the correct fix; it actually is as evidenced by the following description of target_xfer_memory (...), which clearly states that the function will return a value of 0 upon a success, or an errno code will be set upon upon failure (which isn't unusual, as typically only errors, not their absents, are typically signaled through shared variables, therefore relies upon the caller to initialize the errno code to 0 prior to calling any function which may signal an error, which the function (load_section_callback) in symfile.c does not properly presently do prior to calling target_xfer_memory (...) which only guarantees to signal failure per it's documented behavior since your check-in of modifications to this function's implementation this past September.) ] (in: target.c) /* Transfer LEN bytes between target address MEMADDR and GDB address MYADDR. Returns 0 for success, errno code for failure (which includes partial transfers -- if you want a more useful response to partial transfers, try either target_read_memory_partial or target_write_memory_partial). */ static int target_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write); > From: Paul Schlie > > 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.) >